（A + B + C）≠（A + C + B）とコンパイラの並べ替え

2つの32ビット整数を追加すると、整数オーバーフローが発生する可能性があります。

uint64_t u64_z = u32_x + u32_y;

このオーバーフローは、32ビット整数の1つが最初にキャストされるか、64ビット整数に追加される場合に回避できます。

uint64_t u64_z = u32_x + u64_a + u32_y;

ただし、コンパイラが追加の順序を変更することを決定した場合：

uint64_t u64_z = u32_x + u32_y + u64_a;

それでも整数オーバーフローが発生する可能性があります。

コンパイラはそのような並べ替えを行うことができますか、それとも、結果の矛盾に気づき、式の順序をそのまま維持することを信頼できますか？

オプティマイザがそのような並べ替えを行う場合でも、C仕様にバインドされているため、そのような並べ替えは次のようになります。

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

根拠：

で始まる

uint64_t u64_z = u32_x + u64_a + u32_y;

加算は左から右に行われます。

整数の昇格規則は、元の式の最初の加算で、u32_xに昇格することを示していuint64_tます。2番目の追加でu32_yは、にも昇格されuint64_tます。

だから、C仕様に準拠するために、任意のオプティマイザは、促進しなければならないu32_xとu32_y64に符号なしの値をビット。これはキャストを追加することと同じです。（実際の最適化はCレベルでは行われませんが、私たちが理解している表記であるため、私はC表記を使用しています。）

コンパイラは、as ifルールの下でのみ並べ替えが許可されます。つまり、並べ替えによって常に指定した順序と同じ結果が得られる場合は、それが許可されます。それ以外の場合（例のように）、そうではありません。

たとえば、次の式があるとします。

i32big1 - i32big2 + i32small

これは、大きいが類似していることがわかっている2つの値を減算し、次に他の小さい値を追加する（したがって、オーバーフローを回避する）ように注意深く作成されており、コンパイラーは次の順序に並べ替えることができます。

(i32small - i32big2) + i32big1

また、問題を回避するために、ターゲットプラットフォームがラップアラウンド付きの2補数演算を使用しているという事実に依存しています。（コンパイラーがレジスターを要求され、たまたま持っている場合、このような並べ替えは賢明かもしれませんi32smallレジスターにすでにし）。

C、C ++、およびObjective-Cには「あたかも」のルールがあります。準拠するプログラムが違いを認識できない限り、コンパイラは好きなように処理できます。

これらの言語では、a + b + cは（a + b）+ cと同じであると定義されています。これとたとえば+（b + c）との違いがわかる場合、コンパイラは順序を変更できません。違いがわからない場合、コンパイラは自由に順序を変更できますが、違いがわからないため、問題ありません。

あなたの例では、b = 64ビット、aおよびc 32ビットの場合、コンパイラは（b + a）+ cまたは（b + c）+ aさえ評価することができます。 （a + c）+ bではありません。違いがわかるからです。

言い換えると、コンパイラーは、コードの動作を本来の動作と異なるものにすることを許可されていません。自分が生成すると思う、または生成する必要があると思うコードを生成する必要はありませんが、コードは、本来あるべき結果を正確に提供します。

標準からの引用：

[注：演算子が通常の連想または可換である場合にのみ、通常の数学規則に従って演算子を再グループ化できます。7たとえば、次のフラグメントでは、int a、b;

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

式ステートメントは、次のように動作します

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

これらの演算子の結合性と優先順位のため。したがって、合計の結果（a + 32760）が次にbに追加され、その結果が5に追加されて、aに割り当てられた値になります。オーバーフローが例外を生成し、intで表現可能な値の範囲が[-32768、+ 32767]であるマシンでは、実装はこの式を次のように書き換えることはできません。

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

aとbの値がそれぞれ-32754と-15の場合、合計a + bは例外を生成しますが、元の式は生成しません。また、式を次のように書き換えることもできません。

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

または

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

aとbの値がそれぞれ4と-8または-17と12であった可能性があるためです。ただし、オーバーフローが例外を生成せず、オーバーフローの結果が元に戻せるマシンでは、上記の式ステートメントは同じ結果が発生するため、上記のいずれかの方法で実装によって書き換えられます。—エンドノート]

コンパイラはそのような並べ替えを行うことができますか、それとも、結果の矛盾に気づき、式の順序をそのまま維持することを信頼できますか？

コンパイラーは、同じ結果が得られる場合にのみ再順序付けできます-ここで、あなたが観察したように、そうしません。

std::common_type追加する前にすべての引数をプロモートする関数テンプレートを作成することもできます。これは安全で、引数の順序や手動キャストに依存しませんが、かなり扱いにくいです。

のビット幅に依存しますunsigned/int。

下の2つは同じではありません（unsigned <= 32ビットの場合）。 u32_x + u32_y0になります。

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.

それらは同じです（unsigned >= 34ビットの場合）。整数プロモーションが発生しました u32_x + u32_y、64ビット演算で加算が発生しました。順序は関係ありません。

UB（unsigned == 33ビット時）です。整数の昇格により、符号付き33ビット演算で加算が発生し、符号付きオーバーフローはUBです。

コンパイラはそのような並べ替えを行うことができますか？

（32ビット数学）：再注文はい、同じ結果が発生しなければならない、そうではないことを再注文OPを提案しています。以下は同じです

// 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);

...結果の不一致に気づき、式の順序をそのまま維持すると信頼できますか？

はい、信頼できますが、OPのコーディング目標は明確ではありません。u32_x + u32_yキャリーは寄付する必要がありますか？OPがその貢献を望む場合、コードは

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);

だがしかし

uint64_t u64_z = u32_x + u32_y + u64_a;