Combien de GCC niveaux d'optimisation sont là?

Nous allons interpréter le code source du CCAG 5.1 pour voir ce qui se passe sur -O100 car il n'est pas clair sur la page de man.

Nous concluons que:

• rien au-dessus de -O3 jusqu'à INT_MAX est le même que -O3, mais qui pourraient facilement changer dans le futur, donc ne comptez pas sur elle.
• CCAG 5.1 pistes de comportement indéfini si vous entrez des nombres entiers plus grands que INT_MAX.
• l'argument ne peut que la somme des chiffres, soit il échoue gracieusement. En particulier, ce qui exclut les entiers négatifs comme -O-1

Se concentrer sur des sous-programmes

D'abord rappeler que GCC est juste un front-end pour cpp, as, cc1, collect2. Un rapide ./XXX --help dit que seul collect2 et cc1 prendre -O, nous allons donc nous concentrer sur eux.

Et:

gcc -v -O100 main.c |& grep 100

donne:

COLLECT_GCC_OPTIONS='-O100' '-v' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1 [[noise]] hello_world.c -O100 -o /tmp/ccetECB5.

donc -O a été transmis aux deux cc1 et collect2.

O en commun.opter

commun.opt est un GCC spécifiques CLI description de l'option de format décrit dans la les éléments internes de la documentation traduits et C par opth-gen.awk et cifo-gen.awk.

Il contient les lignes intéressantes:

O
Common JoinedOrMissing Optimization
-O<number>  Set optimization level to <number>

Os
Common Optimization
Optimize for space rather than speed

Ofast
Common Optimization
Optimize for speed disregarding exact standards compliance

Og
Common Optimization
Optimize for debugging experience rather than speed or size

qui précisent tous les O options. Notez comment -O<n> est dans une famille séparée de l'autre Os, Ofast et Og.

Lorsque nous construisons, ce qui génère une options.h fichier qui contient:

OPT_O = 139,                               /* -O */
OPT_Ofast = 140,                           /* -Ofast */
OPT_Og = 141,                              /* -Og */
OPT_Os = 142,                              /* -Os */

Comme un bonus, alors que nous sommes grepping pour \bO\n à l'intérieur de common.opt on remarque les lignes:

-optimize
Common Alias(O)

qui nous apprend que --optimize (double dash, car il commence par un tiret -optimize sur le .opt fichier) est un sans-papiers alias pour -O qui peut être utilisé comme --optimize=3!

Où OPT_O est utilisé

Maintenant, nous grep:

git grep -E '\bOPT_O\b'

qui nous renvoie à deux fichiers:

• opte.c
• lto-wrapper.c

Commençons d'abord par la piste vers le bas opts.c

opte.c:default_options_optimization

Tous opts.c usages se produisent à l'intérieur: default_options_optimization.

Nous grep revenir en arrière pour voir qui appelle cette fonction, et nous voyons que le seul chemin d'accès du code:

• main.c:main
• toplev.c:toplev::main
• opts-global.c:decode_opts
• opts.c:default_options_optimization

et main.c est le point d'entrée de cc1. Bon!

La première partie de cette fonction:

• ne integral_argument qui appelle atoi sur la chaîne de caractères correspondant à OPT_O pour analyser l'argument d'entrée
• stocke la valeur à l'intérieur de opts->x_optimize où opts est un struct gcc_opts.

struct gcc_opts

Après grepping en vain, nous remarquons que cette struct est également généré à options.h:

struct gcc_options {
    int x_optimize;
    [...]
}

où x_optimize vient de l'lignes:

Variable
int optimize

présents dans common.opt, et que options.c:

struct gcc_options global_options;

donc on suppose que c'est ce que contient l'intégralité de la configuration globale de l'état, et int x_optimize est l'optimisation de la valeur.

255 interne est un maximum

dans opts.c:integral_argument, atoi est appliqué à l'entrée de l'argument, de sorte INT_MAX est une limite supérieure. Et si vous mettez quelque chose de plus, il semble que la GCC s'exécute C un comportement indéterminé. Ouch?

integral_argument aussi finement enveloppements atoi et rejette l'argument si aucun caractère n'est pas un chiffre. Si négatif valeurs ne sont pas gracieusement.

Retour à opts.c:default_options_optimization, nous voyons la ligne:

if ((unsigned int) opts->x_optimize > 255)
  opts->x_optimize = 255;

de sorte que le niveau d'optimisation est tronqué à 255. Lors de la lecture de opth-gen.awk j'étais venu dans:

# All of the optimization switches gathered together so they can be saved and restored.
# This will allow attribute((cold)) to turn on space optimization.

et sur le options.h:

struct GTY(()) cl_optimization
{
  unsigned char x_optimize;

ce qui explique pourquoi la troncature: les options doivent également être transmis à cl_optimization, qui utilise un char pour économiser de l'espace. Donc 255 interne est un maximum de la réalité.

opte.c:maybe_default_options

Retour à opts.c:default_options_optimization, nous croisons maybe_default_options qui semble intéressant. Nous y entrons, et puis maybe_default_option où nous arrivons à un grand changement:

switch (default_opt->levels)
  {

  [...]

  case OPT_LEVELS_1_PLUS:
    enabled = (level >= 1);
    break;

  [...]

  case OPT_LEVELS_3_PLUS:
    enabled = (level >= 3);
    break;

Il n'y a pas >= 4 contrôles, ce qui indique que 3 est le plus grand possible.

Puis on recherche la définition de OPT_LEVELS_3_PLUS dans common-target.h:

enum opt_levels
{
  OPT_LEVELS_NONE, /* No levels (mark end of array).  */
  OPT_LEVELS_ALL, /* All levels (used by targets to disable options
                     enabled in target-independent code).  */
  OPT_LEVELS_0_ONLY, /* -O0 only.  */
  OPT_LEVELS_1_PLUS, /* -O1 and above, including -Os and -Og.  */
  OPT_LEVELS_1_PLUS_SPEED_ONLY, /* -O1 and above, but not -Os or -Og.  */
  OPT_LEVELS_1_PLUS_NOT_DEBUG, /* -O1 and above, but not -Og.  */
  OPT_LEVELS_2_PLUS, /* -O2 and above, including -Os.  */
  OPT_LEVELS_2_PLUS_SPEED_ONLY, /* -O2 and above, but not -Os or -Og.  */
  OPT_LEVELS_3_PLUS, /* -O3 and above.  */
  OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and -Os.  */
  OPT_LEVELS_SIZE, /* -Os only.  */
  OPT_LEVELS_FAST /* -Ofast only.  */
};

Ha! C'est un indicateur fort que il y a que 3 niveaux.

opte.c:default_options_table

opt_levels est si intéressant, que nous grep OPT_LEVELS_3_PLUS, et viennent à travers opts.c:default_options_table:

static const struct default_options default_options_table[] = {
    /* -O1 optimizations.  */
    { OPT_LEVELS_1_PLUS, OPT_fdefer_pop, NULL, 1 },
    [...]

    /* -O3 optimizations.  */
    { OPT_LEVELS_3_PLUS, OPT_ftree_loop_distribute_patterns, NULL, 1 },
    [...]
}

c'est donc là que le -On spécifiques d'optimisation de la cartographie mentionné dans les docs sont codées. Nice!

Assurer qu'il n'y a pas plus d'utilisations pour les x_optimize

L'usage principal de x_optimize était de définir d'autres options d'optimisation comme -fdefer_pop comme indiqué sur la page de man. Sont plus là?

Nous grep, et de trouver un peu plus. Le nombre est petit, et lors de l'inspection manuelle, nous voyons que chaque utilisation seulement à plus d'un x_optimize >= 3, de sorte que notre conclusion est titulaire d'.

lto-wrapper.c

Maintenant, nous allons pour la deuxième occurrence de OPT_O, qui était dans lto-wrapper.c.

LTO moyens de Liaison à l'Optimisation du Temps, qui, comme son nom l'indique va avoir besoin d'un -O option, et est liée à collec2 (qui est en fait un éditeur de liens).

En fait, la première ligne de lto-wrapper.c dit:

/* Wrapper to call lto.  Used by collect2 and the linker plugin.

Dans ce fichier, le OPT_O occurrences semble être la seule à normaliser la valeur de O pour passer de l'avant, de sorte que nous devrions être bien.

Quatre (0-3): Voir la GCC 4.4.2 manuel. Rien de plus juste-O3, mais à un certain moment vous permettra de dépassement de la limite de taille variable.