assembly o3 - Pourquoi GCC n'optimise-t-il pas un * a * a * a * a * a à(a * a * a)*(a * a * a)?




optimization bug (11)

Je suis en train d’optimiser numériquement une application scientifique. Une chose que j’ai remarquée est que GCC optimisera le pow(a,2) appel pow(a,2) en le compilant en a*a , mais l’appel pow(a,6) n’est pas optimisé et appellera en fait la fonction de bibliothèque pow , ce qui ralentit considérablement la performance. (En revanche, Intel C ++ Compiler , exécutable icc , éliminera l’appel de bibliothèque pour pow(a,6) .)

Ce que je suis curieux de savoir, c’est que lorsque je remplace pow(a,6) par a*a*a*a*a*a aide de GCC 4.5.1 et des options " -O3 -lm -funroll-loops -msse4 ", il utilise 5 instructions mulsd :

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13

alors que si j'écris (a*a*a)*(a*a*a) , cela produira

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm13, %xmm13

ce qui réduit le nombre d'instructions de multiplication à 3. icc a un comportement similaire.

Pourquoi les compilateurs ne reconnaissent-ils pas cette astuce d'optimisation?


Answers

Fortran (conçu pour l'informatique scientifique) a un opérateur de puissance intégré et, autant que je sache, les compilateurs Fortran optimisent généralement l'augmentation des puissances de nombres entiers de la même manière que ce que vous décrivez. C / C ++, malheureusement, n’a pas d’opérateur électrique, seulement la fonction de bibliothèque pow() . Cela n'empêche pas les compilateurs intelligents de traiter spécialement le pow et de le calculer plus rapidement dans des cas particuliers, mais il semble qu'ils le fassent moins fréquemment ...

Il y a quelques années, j'essayais de rendre plus pratique le calcul optimal des puissances entières. C'est du C ++, pas du C cependant, et cela dépend toujours du compilateur qui est assez intelligent pour optimiser les choses / en ligne. Quoi qu'il en soit, j'espère que vous pourrez le trouver utile dans la pratique:

template<unsigned N> struct power_impl;

template<unsigned N> struct power_impl {
    template<typename T>
    static T calc(const T &x) {
        if (N%2 == 0)
            return power_impl<N/2>::calc(x*x);
        else if (N%3 == 0)
            return power_impl<N/3>::calc(x*x*x);
        return power_impl<N-1>::calc(x)*x;
    }
};

template<> struct power_impl<0> {
    template<typename T>
    static T calc(const T &) { return 1; }
};

template<unsigned N, typename T>
inline T power(const T &x) {
    return power_impl<N>::calc(x);
}

Précision pour les curieux: cela ne trouve pas le moyen optimal de calculer les puissances, mais comme trouver la solution optimale est un problème NP-complet et que cela ne vaut que pour les petites puissances (par opposition à l’utilisation de pow ), il n’ya aucune raison de le faire. faire du bruit avec les détails.

Ensuite, utilisez-le simplement comme power<6>(a) .

Cela facilite la -ffast-math pouvoirs (pas besoin d’écrire 6 a s avec des parens), et vous permet d’avoir ce type d’optimisation sans -ffast-math si vous avez quelque chose qui dépend de la précision, telle que la sommation compensée (un exemple où l’ordre des opérations est indispensable).

Vous pouvez aussi probablement oublier qu'il s'agit de C ++ et l'utiliser simplement dans le programme C (s'il compile avec un compilateur C ++).

J'espère que cela peut être utile.

MODIFIER:

Voici ce que je tire de mon compilateur:

Pour a*a*a*a*a*a ,

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0

Pour (a*a*a)*(a*a*a) ,

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm0, %xmm0

Pour le power<6>(a) ,

    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm0, %xmm1

Aucune affiche n'a encore mentionné la contraction des expressions flottantes (norme ISO C, 6.5p8 et 7.12.2). Si le pragma FP_CONTRACT est défini sur ON , le compilateur est autorisé à considérer une expression telle que a*a*a*a*a*a comme une opération unique, comme si elle était évaluée exactement avec un arrondi unique. Par exemple, un compilateur peut le remplacer par une fonction d'alimentation interne à la fois plus rapide et plus précise. Ceci est particulièrement intéressant car le comportement est partiellement contrôlé par le programmeur directement dans le code source, alors que les options du compilateur fournies par l'utilisateur final peuvent parfois être utilisées de manière incorrecte.

L'état par défaut du pragma FP_CONTRACT est défini par l'implémentation, de sorte qu'un compilateur est autorisé à effectuer ces optimisations par défaut. Par conséquent, le code portable devant respecter scrupuleusement les règles IEEE 754 doit le définir explicitement sur OFF .

Si un compilateur ne supporte pas ce pragma, il doit être prudent en évitant une telle optimisation, au cas où le développeur aurait choisi de le OFF .

GCC ne supporte pas ce pragma, mais avec les options par défaut, il suppose qu'il est ON ; ainsi pour les cibles avec un FMA matériel, si on veut empêcher la transformation a*b+c en fma (a, b, c), il faut fournir une option telle que -ffp-contract=off (pour définir explicitement le pragma to OFF ) ou -std=c99 (pour indiquer à GCC de se conformer à une version standard de C, ici C99, suivez donc le paragraphe ci-dessus). Dans le passé, cette dernière option n’empêchait pas la transformation, ce qui signifie que GCC n’était pas en conformité sur ce point: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845


gcc peut réellement faire cette optimisation, même pour les nombres à virgule flottante. Par exemple,

double foo(double a) {
  return a*a*a*a*a*a;
}

devient

foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret

avec -O -funsafe-math-optimizations . Cette réorganisation enfreint IEEE-754, cependant, elle nécessite le drapeau.

Comme Peter Cordes l'a souligné dans un commentaire, les entiers signés peuvent effectuer cette optimisation sans -funsafe-math-optimizationsque cela soit valable, car il existe exactement quand il n'y a pas de dépassement de capacité et en cas de dépassement de capacité, vous obtenez un comportement non défini. Donc vous obtenez

foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret

avec juste -O. Pour les entiers non signés, c'est encore plus facile, car ils travaillent avec une puissance de 2 et peuvent donc être réorganisés librement, même en cas de dépassement de capacité.


Comme Lambdageek l'a souligné, la multiplication flottante n'est pas associative et vous pouvez obtenir moins de précision, mais lorsque vous obtenez une meilleure précision, vous pouvez vous opposer à l'optimisation, car vous souhaitez une application déterministe. Par exemple, dans la simulation de jeu client / serveur, où chaque client doit simuler le même monde pour lequel les calculs en virgule flottante doivent être déterministes.


Lambdageek souligne à juste titre que l’optimisation d’ a*a*a*a*a*a à (a*a*a)*(a*a*a) peut changer la valeur. C'est pourquoi il est interdit par C99 (sauf autorisation expresse de l'utilisateur, via un indicateur de compilation ou un pragma). En règle générale, l'hypothèse est que la programmeuse a écrit ce qu'elle a fait pour une raison et que le compilateur devrait respecter cela. Si vous voulez (a*a*a)*(a*a*a) , écrivez cela.

Cela peut être pénible à écrire, cependant; pourquoi le compilateur ne peut-il pas simplement faire [ce que vous considérez être] la bonne chose lorsque vous utilisez pow(a,6) ? Parce que ce serait la mauvaise chose à faire. Sur une plate-forme avec une bonne bibliothèque mathématique, pow(a,6) est nettement plus précis que soit a*a*a*a*a*a ou (a*a*a)*(a*a*a) . Juste pour fournir des données, j'ai effectué une petite expérience sur mon Mac Pro, mesurant la pire erreur lors de l'évaluation de ^ 6 pour tous les nombres flottants à simple précision compris entre [1,2):

worst relative error using    powf(a, 6.f): 5.96e-08
worst relative error using (a*a*a)*(a*a*a): 2.94e-07
worst relative error using     a*a*a*a*a*a: 2.58e-07

L'utilisation de pow au lieu d'un arbre de multiplication réduit l'erreur liée d'un facteur 4 . Les compilateurs ne devraient pas (et ne font généralement pas) faire des "optimisations" qui augmentent l'erreur sauf si l'utilisateur le permet (par exemple via -ffast-math ).

Notez que GCC fournit __builtin_powi(x,n) comme alternative à pow( ) , ce qui devrait générer un arbre de multiplication en ligne. Utilisez-le si vous voulez échanger précision et performance, mais ne souhaitez pas activer le calcul rapide.


Un autre cas similaire: la plupart des compilateurs n’optimiseront pas a + b + c + d en (a + b) + (c + d) (c’est une optimisation puisque la seconde expression peut être mieux canalisée) et l’évaluera comme donnée (ie comme (((a + b) + c) + d) ). C'est aussi à cause des cas de coin:

float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));

Cette sortie 1.000000e-05 0.000000e+00


Les fonctions de bibliothèque telles que "pow" sont généralement soigneusement conçues pour générer le minimum d'erreur possible (en cas générique). Ceci est généralement réalisé en approximant des fonctions avec des splines (selon le commentaire de Pascal, l'implémentation la plus courante semble utiliser l' algorithme de Remez )

fondamentalement l'opération suivante:

pow(x,y);

a une erreur inhérente d'approximativement la même ampleur que l'erreur de toute multiplication ou division .

Alors que l'opération suivante:

float a=someValue;
float b=a*a*a*a*a*a;

a une erreur inhérente qui est supérieure à 5 fois celle d'une multiplication ou d'une division unique (parce que vous combinez 5 multiplications).

Le compilateur devrait être très attentif au type d'optimisation qu'il effectue:

  1. si l'optimisation de pow(a,6) en a*a*a*a*a*a peut améliorer les performances, mais réduire considérablement la précision des nombres à virgule flottante.
  2. en optimisant a*a*a*a*a*a à pow(a,6) la précision peut en être réduite car "a" était une valeur spéciale qui permet une multiplication sans erreur (une puissance de 2 ou un petit nombre entier)
  3. si l'optimisation de pow(a,6) à (a*a*a)*(a*a*a) ou (a*a)*(a*a)*(a*a) peut encore entraîner une perte de précision par rapport à la fonction de pow .

En général, vous savez que pour des valeurs à virgule flottante arbitraires, "pow" a une meilleure précision que toute fonction que vous pourriez éventuellement écrire, mais dans certains cas particuliers, plusieurs multiplications peuvent avoir une précision et des performances meilleures, il appartient au développeur de choisir celle qui convient le mieux, éventuellement commenter le code de sorte que personne ne «optimise» ce code.

La seule chose qui ait du sens (opinion personnelle, et apparemment un choix dans GCC sans optimisation particulière ou indicateur du compilateur) à optimiser devrait être de remplacer "pow (a, 2)" par "a * a". Ce serait la seule chose saine qu'un vendeur de compilateur devrait faire.


GCC optimise effectivement un * a * a * a * a * a à (a * a * a) * (a * a * a) quand a est un entier. J'ai essayé avec cette commande:

$ echo 'int f(int x) { return x*x*x*x*x*x; }' | gcc -o - -O2 -S -masm=intel -x c -

Il y a beaucoup de drapeaux gcc mais rien d'extraordinaire. Ils veulent dire: Read from stdin; utiliser le niveau d'optimisation de l'O2; liste de langage d'assemblage de sortie au lieu d'un binaire; la liste doit utiliser la syntaxe du langage d'assemblage Intel; l'entrée est en langage C (généralement la langue est déduite de l'extension du fichier d'entrée, mais il n'y a pas d'extension de fichier lors de la lecture de stdin); et écrivez sur stdout.

Voici la partie importante de la sortie. Je l'ai annoté avec quelques commentaires indiquant ce qui se passe dans le langage d'assemblage:

    ; x is in edi to begin with.  eax will be used as a temporary register.
    mov    eax, edi     ; temp1 = x
    imul    eax, edi    ; temp2 = x * temp1
    imul    eax, edi    ; temp3 = x * temp2
    imul    eax, eax    ; temp4 = temp3 * temp3

J'utilise le système GCC sous Linux Mint 16 Petra, un dérivé d'Ubuntu. Voici la version gcc:

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

Comme d'autres auteurs l'ont noté, cette option n'est pas possible en virgule flottante, car l'arithmétique en virgule flottante n'est en réalité pas associative.


Parce que le calcul en virgule flottante n'est pas associatif . La façon dont vous regroupez les opérandes en multiplication à virgule flottante a une incidence sur la précision numérique de la réponse.

En conséquence, la plupart des compilateurs sont très prudents quant à la réorganisation des calculs en virgule flottante, à moins qu'ils ne puissent être certains que la réponse reste la même ou à moins que vous leur disiez que vous ne vous souciez pas de la précision numérique. Par exemple: l'option -fassociative-math de gcc, qui permet à gcc de réassocier des opérations en virgule flottante, ou encore l'option -ffast-math , qui permet des compromis encore plus agressifs entre précision et rapidité.


Il y a déjà quelques bonnes réponses à cette question, mais par souci d'exhaustivité, je voudrais souligner que la section applicable de la norme C est 5.1.2.2.3 / 15 (ce qui correspond à la section 1.9 / 9 de la C ++ 11 standard). Cette section indique que les opérateurs ne peuvent être regroupés que s'ils sont réellement associatifs ou commutatifs.


Parce que linux est une macro intégrée définie lorsque le compilateur est en cours d'exécution, ou la compilation pour (s'il s'agit d'un compilateur croisé), Linux.

Il y a beaucoup de ces macros prédéfinies. Avec GCC, vous pouvez utiliser:

cp /dev/null emptyfile.c
gcc -E -dM emptyfile.c

pour obtenir une liste de macros. (Je n'ai pas réussi à persuader GCC d'accepter /dev/null directement, mais le fichier vide semble fonctionner correctement.) Avec GCC 4.8.1 fonctionnant sous Mac OS X 10.8.5, j'ai obtenu la sortie:

#define __DBL_MIN_EXP__ (-1021)
#define __UINT_LEAST16_MAX__ 65535
#define __ATOMIC_ACQUIRE 2
#define __FLT_MIN__ 1.17549435082228750797e-38F
#define __UINT_LEAST8_TYPE__ unsigned char
#define __INTMAX_C(c) c ## L
#define __CHAR_BIT__ 8
#define __UINT8_MAX__ 255
#define __WINT_MAX__ 2147483647
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 18446744073709551615UL
#define __WCHAR_MAX__ 2147483647
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L)
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __FLT_EVAL_METHOD__ 0
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __x86_64 1
#define __UINT_FAST64_MAX__ 18446744073709551615ULL
#define __SIG_ATOMIC_TYPE__ int
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 1
#define __UINT_FAST8_MAX__ 255
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __UINT_LEAST64_MAX__ 18446744073709551615ULL
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINT_LEAST8_MAX__ 255
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __APPLE_CC__ 1
#define __UINTMAX_TYPE__ long unsigned int
#define __DEC32_EPSILON__ 1E-6DF
#define __UINT32_MAX__ 4294967295U
#define __LDBL_MAX_EXP__ 16384
#define __WINT_MIN__ (-__WINT_MAX__ - 1)
#define __SCHAR_MAX__ 127
#define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
#define __INT64_C(c) c ## LL
#define __DBL_DIG__ 15
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 8
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.19209289550781250000e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __DEC32_MAX__ 9.999999E96DF
#define __strong 
#define __INT32_MAX__ 2147483647
#define __SIZEOF_LONG__ 8
#define __APPLE__ 1
#define __UINT16_C(c) c
#define __DECIMAL_DIG__ 21
#define __LDBL_HAS_QUIET_NAN__ 1
#define __DYNAMIC__ 1
#define __GNUC__ 4
#define __MMX__ 1
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 16
#define __BIGGEST_ALIGNMENT__ 16
#define __DBL_MAX__ ((double)1.79769313486231570815e+308L)
#define __INT_FAST32_MAX__ 2147483647
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __INT_FAST16_TYPE__ short int
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __INT_LEAST32_MAX__ 2147483647
#define __DEC32_MIN__ 1E-95DF
#define __weak 
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __SSE2_MATH__ 1
#define __ATOMIC_HLE_RELEASE 131072
#define __PTRDIFF_MAX__ 9223372036854775807L
#define __amd64 1
#define __tune_core2__ 1
#define __ATOMIC_HLE_ACQUIRE 65536
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __SIZEOF_SIZE_T__ 8
#define __SIZEOF_WINT_T__ 4
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __INT_FAST64_TYPE__ long long int
#define __DBL_MIN__ ((double)2.22507385850720138309e-308L)
#define __LP64__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__ 
#define __UINT16_MAX__ 65535
#define __DBL_HAS_DENORM__ 1
#define __UINT8_TYPE__ unsigned char
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.8.1"
#define __UINT64_C(c) c ## ULL
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __INT32_C(c) c
#define __DEC64_EPSILON__ 1E-15DD
#define __ORDER_PDP_ENDIAN__ 3412
#define __DEC128_MIN_EXP__ (-6142)
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __INT16_MAX__ 32767
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1080
#define __SIZE_TYPE__ long unsigned int
#define __UINT64_MAX__ 18446744073709551615ULL
#define __INT8_TYPE__ signed char
#define __FLT_RADIX__ 2
#define __INT_LEAST16_TYPE__ short int
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __UINTMAX_C(c) c ## UL
#define __SSE_MATH__ 1
#define __k8 1
#define __SIG_ATOMIC_MAX__ 2147483647
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __SIZEOF_PTRDIFF_T__ 8
#define __x86_64__ 1
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __INT_FAST16_MAX__ 32767
#define __UINT_FAST32_MAX__ 4294967295U
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 9223372036854775807L
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __UINT_FAST16_TYPE__ short unsigned int
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __CHAR16_TYPE__ short unsigned int
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __INT_LEAST16_MAX__ 32767
#define __DEC64_MANT_DIG__ 16
#define __INT64_MAX__ 9223372036854775807LL
#define __UINT_LEAST32_MAX__ 4294967295U
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __INT_LEAST64_TYPE__ long long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __DEC32_MAX_EXP__ 97
#define __INT_FAST8_MAX__ 127
#define __INTPTR_MAX__ 9223372036854775807L
#define __LITTLE_ENDIAN__ 1
#define __SSE2__ 1
#define __LDBL_MANT_DIG__ 64
#define __CONSTANT_CFSTRINGS__ 1
#define __DBL_HAS_QUIET_NAN__ 1
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __code_model_small__ 1
#define __k8__ 1
#define __INTPTR_TYPE__ long int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ int
#define __SIZEOF_FLOAT__ 4
#define __pic__ 2
#define __UINTPTR_MAX__ 18446744073709551615UL
#define __DEC64_MIN_EXP__ (-382)
#define __INT_FAST64_MAX__ 9223372036854775807LL
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __FLT_DIG__ 6
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT_MAX__ 2147483647
#define __MACH__ 1
#define __amd64__ 1
#define __INT64_TYPE__ long long int
#define __FLT_MAX_EXP__ 128
#define __ORDER_BIG_ENDIAN__ 4321
#define __DBL_MANT_DIG__ 53
#define __INT_LEAST64_MAX__ 9223372036854775807LL
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __SSE__ 1
#define __LDBL_MIN_EXP__ (-16381)
#define __INT_LEAST8_MAX__ 127
#define __SIZEOF_INT128__ 16
#define __LDBL_MAX_10_EXP__ 4932
#define __ATOMIC_RELAXED 0
#define __DBL_EPSILON__ ((double)2.22044604925031308085e-16L)
#define _LP64 1
#define __UINT8_C(c) c
#define __INT_LEAST32_TYPE__ int
#define __SIZEOF_WCHAR_T__ 4
#define __UINT64_TYPE__ long long unsigned int
#define __INT_FAST8_TYPE__ signed char
#define __DBL_DECIMAL_DIG__ 17
#define __FXSR__ 1
#define __DEC_EVAL_METHOD__ 2
#define __UINT32_C(c) c ## U
#define __INTMAX_MAX__ 9223372036854775807L
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT_DENORM_MIN__ 1.40129846432481707092e-45F
#define __INT8_MAX__ 127
#define __PIC__ 2
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.40282346638528859812e+38F
#define __INT32_TYPE__ int
#define __SIZEOF_DOUBLE__ 8
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long int
#define __DEC128_MAX_EXP__ 6145
#define __ATOMIC_CONSUME 1
#define __GNUC_MINOR__ 8
#define __UINTMAX_MAX__ 18446744073709551615UL
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __INT16_C(c) c
#define __STDC__ 1
#define __PTRDIFF_TYPE__ long int
#define __ATOMIC_SEQ_CST 5
#define __UINT32_TYPE__ unsigned int
#define __UINTPTR_TYPE__ long unsigned int
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-4931)
#define __SIZEOF_LONG_LONG__ 8
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __LDBL_DIG__ 18
#define __FLT_DECIMAL_DIG__ 9
#define __UINT_FAST16_MAX__ 65535
#define __GNUC_GNU_INLINE__ 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
#define __SSE3__ 1
#define __UINT_FAST8_TYPE__ unsigned char
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_RELEASE 3

C'est 236 macros d'un fichier vide. Lorsque j'ai ajouté #include <stdio.h> au fichier, le nombre de macros définies est passé à 505. Cela inclut toutes sortes de macros d'identification de plate-forme.





gcc assembly floating-point compiler-optimization fast-math