(A + B + C) ≠ (A + C + B) et réorganisation du compilateur

L'ajout de deux entiers 32 bits peut entraîner un débordement d'entier:

uint64_t u64_z = u32_x + u32_y;

Ce débordement peut être évité si l'un des entiers 32 bits est d'abord converti ou ajouté à un entier 64 bits.

uint64_t u64_z = u32_x + u64_a + u32_y;

Cependant, si le compilateur décide de réorganiser l'ajout:

uint64_t u64_z = u32_x + u32_y + u64_a;

le dépassement d'entier peut encore se produire.

Les compilateurs sont-ils autorisés à effectuer une telle réorganisation ou pouvons-nous leur faire confiance pour remarquer l'incohérence du résultat et conserver l'ordre des expressions tel quel?

Si l'optimiseur effectue une telle réorganisation, il est toujours lié à la spécification C, donc une telle réorganisation deviendrait:

uint64_t u64_z = (uint64_t)u32_x + (uint64_t)u32_y + u64_a;

Raisonnement:

Nous commençons par

uint64_t u64_z = u32_x + u64_a + u32_y;

L'addition est effectuée de gauche à droite.

Les règles de promotion d'entiers indiquent que lors du premier ajout dans l'expression d'origine, u32_xêtre promu en uint64_t. Dans le deuxième ajout, u32_ysera également promu à uint64_t.

Ainsi, afin d'être conforme à la spécification C, tout Optimiseur doit promouvoir u32_xet u32_yà 64 bits des valeurs non signées. Cela équivaut à ajouter une distribution. (L'optimisation proprement dite ne se fait pas au niveau C, mais j'utilise la notation C car c'est une notation que nous comprenons.)

Un compilateur n'est autorisé à réorganiser que sous la règle comme si . Autrement dit, si la réorganisation donnera toujours le même résultat que la commande spécifiée, alors elle est autorisée. Sinon (comme dans votre exemple), non.

Par exemple, étant donné l'expression suivante

i32big1 - i32big2 + i32small

qui a été soigneusement construit pour soustraire les deux valeurs qui sont connues pour être grandes mais similaires, et ensuite seulement ajouter l'autre petite valeur (évitant ainsi tout débordement), le compilateur peut choisir de réorganiser en:

(i32small - i32big2) + i32big1

et comptez sur le fait que la plate-forme cible utilise l'arithmétique à deux compléments avec enveloppement pour éviter les problèmes. (Une telle réorganisation peut être judicieuse si le compilateur est pressé pour les registres, et se trouve déjà i32smalldans un registre).

Il existe la règle du «comme si» en C, C ++ et Objective-C: le compilateur peut faire ce qu'il veut tant qu'aucun programme conforme ne peut faire la différence.

Dans ces langages, a + b + c est défini comme étant identique à (a + b) + c. Si vous pouvez faire la différence entre ceci et par exemple a + (b + c), alors le compilateur ne peut pas changer l'ordre. Si vous ne pouvez pas faire la différence, le compilateur est libre de modifier l'ordre, mais c'est très bien, car vous ne pouvez pas faire la différence.

Dans votre exemple, avec b = 64 bits, a et c 32 bits, le compilateur serait autorisé à évaluer (b + a) + c ou même (b + c) + a, car vous ne pouviez pas faire la différence, mais pas (a + c) + b parce que vous pouvez faire la différence.

En d'autres termes, le compilateur n'est pas autorisé à faire quoi que ce soit qui fasse que votre code se comporte différemment de ce qu'il devrait. Il n'est pas nécessaire de produire le code que vous pensez qu'il produirait, ou que vous pensez qu'il devrait produire, mais le code va vous donner exactement les résultats qu'elle devrait.

Citant les normes :

[Note: Les opérateurs peuvent être regroupés selon les règles mathématiques habituelles uniquement lorsque les opérateurs sont réellement associatifs ou commutatifs.7 Par exemple, dans le fragment suivant int a, b;

/∗ ... ∗/
a = a + 32760 + b + 5;

l'instruction d'expression se comporte exactement de la même manière que

a = (((a + 32760) + b) + 5);

en raison de l'associativité et de la priorité de ces opérateurs. Ainsi, le résultat de la somme (a + 32760) est ensuite ajouté à b, et ce résultat est ensuite ajouté à 5, ce qui donne la valeur attribuée à a. Sur une machine dans laquelle les débordements produisent une exception et dans laquelle la plage de valeurs représentables par un int est [-32768, + 32767], l'implémentation ne peut pas réécrire cette expression comme

a = ((a + b) + 32765);

puisque si les valeurs pour a et b étaient respectivement -32754 et -15, la somme a + b produirait une exception alors que l'expression originale ne le ferait pas; l'expression ne peut pas non plus être réécrite comme

a = ((a + 32765) + b);

ou

a = (a + (b + 32765));

puisque les valeurs de a et b auraient pu être respectivement 4 et -8 ou -17 et 12. Cependant sur une machine dans laquelle les débordements ne produisent pas d'exception et dans laquelle les résultats des débordements sont réversibles, l'instruction d'expression ci-dessus peut être réécrit par l'implémentation de l'une des manières ci-dessus car le même résultat se produira. - note de fin]

Les compilateurs sont-ils autorisés à effectuer une telle réorganisation ou pouvons-nous leur faire confiance pour remarquer l'incohérence du résultat et conserver l'ordre des expressions tel quel?

Le compilateur ne peut réorganiser que s'il donne le même résultat - ici, comme vous l'avez observé, ce n'est pas le cas.

Il est possible d'écrire un modèle de fonction, si vous en voulez un, qui promeut tous les arguments std::common_typeavant l'ajout - ce serait sûr, et ne dépendrait ni de l'ordre des arguments ni de la conversion manuelle, mais c'est assez maladroit.

Cela dépend de la largeur de bits de unsigned/int.

Les 2 ci-dessous ne sont pas les mêmes (lorsque les unsigned <= 32bits). u32_x + u32_ydevient 0.

u64_a = 0; u32_x = 1; u32_y = 0xFFFFFFFF;
uint64_t u64_z = u32_x + u64_a + u32_y;
uint64_t u64_z = u32_x + u32_y + u64_a;  // u32_x + u32_y carry does not add to sum.

Ce sont les mêmes (quand unsigned >= 34bits). Les promotions de nombres entiers ont provoqué l' u32_x + u32_yajout en maths 64 bits. L'ordre n'a pas d'importance.

C'est UB (quand unsigned == 33bits). Les promotions entières ont provoqué l'ajout au niveau des maths 33 bits signés et le débordement signé est UB.

Les compilateurs sont-ils autorisés à effectuer une telle réorganisation ...?

(Math 32 bits): Réorganiser oui, mais les mêmes résultats doivent se produire, donc pas ce que OP propose de réordonner. Ci-dessous sont les mêmes

// Same
u32_x + u64_a + u32_y;
u64_a + u32_x + u32_y;
u32_x + (uint64_t) u32_y + u64_a;
...

// Same as each other below, but not the same as the 3 above.
uint64_t u64_z = u32_x + u32_y + u64_a;
uint64_t u64_z = u64_a + (u32_x + u32_y);

... pouvons-nous leur faire confiance pour remarquer l'incohérence du résultat et conserver l'ordre des expressions tel quel?

Faites confiance, mais l'objectif de codage d'OP n'est pas clair. Le u32_x + u32_ycarry devrait-il contribuer? Si OP veut cette contribution, le code doit être

uint64_t u64_z = u64_a + u32_x + u32_y;
uint64_t u64_z = u32_x + u64_a + u32_y;
uint64_t u64_z = u32_x + (u32_y + u64_a);

Mais non

uint64_t u64_z = u32_x + u32_y + u64_a;