コンパイラが予測可能な加算ループを乗算に最適化できない（またはできない）のはなぜですか？

これは、質問に対するMysticialの素晴らしい答えを読んでいるときに思い浮かんだ質問です。なぜ、ソートされていない配列よりもソートされた配列を処理する方が速いのですか？

関連するタイプのコンテキスト：

const unsigned arraySize = 32768;
int data[arraySize];
long long sum = 0;

彼の答えで彼はIntel Compiler（ICC）がこれを最適化すると説明しています：

for (int i = 0; i < 100000; ++i)
    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            sum += data[c];

...これと同等のものに：

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

オプティマイザはこれらが同等であることを認識しているため、ループを交換し、内部ループの外に分岐を移動しています。非常に賢い！

しかし、なぜこれを行わないのですか？

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000 * data[c];

うまくいけば、ミスティック（または他の誰でも）も同様に素晴らしい答えを出すことができます。これまでに他の質問で説明した最適化について学んだことがないので、本当にありがたいです。

コンパイラは一般に変換できません

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

に

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000 * data[c];

後者は前者がしないのに符号付き整数のオーバーフローを引き起こす可能性があるためです。符号付き2の補数整数のオーバーフローに対するラップアラウンド動作が保証されていても、結果が変化します（data[c]30000の場合、製品はラップアラウンド付きの-1294967296一般的な32ビットintsにsumなります。オーバーフローしない、sum3000000000 増加）。同じことが符号なしの数量にも当てはまり、数値が異なる場合、オーバーフローにより、100000 * data[c]通常2^32、最終結果に現れてはならない剰余法が導入されることに注意してください。

それはそれを

for (int c = 0; c < arraySize; ++c)
    if (data[c] >= 128)
        sum += 100000LL * data[c];  // resp. 100000ull

ただし、通常どおり、long longが十分に大きい場合int。

なぜそれができないのか、私にはわかりません、おそらくMysticialが言ったのだと思います。

ループ交換自体は一般に有効ではないことに注意してください（符号付き整数の場合）。

for (int c = 0; c < arraySize; ++c)
    if (condition(data[c]))
        for (int i = 0; i < 100000; ++i)
            sum += data[c];

オーバーフローを引き起こす可能性があります

for (int i = 0; i < 100000; ++i)
    for (int c = 0; c < arraySize; ++c)
        if (condition(data[c]))
            sum += data[c];

しません。data[c]追加されたすべての要素が同じ符号を持つことを条件が保証するため、ここではコーシャです。一方がオーバーフローすると、両方がそうなります。

コンパイラがそれを考慮に入れたかどうかはあまりわかりません（@Mysticial、data[c] & 0x80正と負の値に当てはまるような条件で試すことができますか？）。コンパイラーに無効な最適化を行わせました（たとえば、2、3年前、ICC（11.0、iirc）で、signed-32-bit-int-to-double変換を使用1.0/nしnましたunsigned int。出力ですが、間違っています。多くの値がより大きいです2^31。

この回答はリンクされた特定のケースには適用されませんが、質問のタイトルには適用され、将来の読者にとって興味深いかもしれません。

有限の精度のため、繰り返しの浮動小数点加算は乗算と同等ではありません。考慮してください：

float const step = 1e-15;
float const init = 1;
long int const count = 1000000000;

float result1 = init;
for( int i = 0; i < count; ++i ) result1 += step;

float result2 = init;
result2 += step * count;

cout << (result1 - result2);

デモ

コンパイラには、最適化を行うさまざまなパスが含まれています。通常、各パスでは、ステートメントの最適化またはループの最適化が行われます。現時点では、ループヘッダーに基づいてループ本体の最適化を行うモデルはありません。これは検出が難しく一般的ではありません。

行われた最適化は、ループ不変のコードモーションでした。これは、一連の手法を使用して実行できます。

まあ、私が整数演算について話していると仮定すると、一部のコンパイラはこの種の最適化を行う可能性があると思います。

同時に、反復加算を乗算で置き換えるとコードのオーバーフロー動作が変わる可能性があるため、一部のコンパイラはそれを拒否する場合があります。符号なし整数型の場合、オーバーフロー動作は言語によって完全に指定されているため、違いはありません。しかし、署名されたものについては、それは可能性があります（おそらく2の補数プラットフォーム上ではありません）。符号付きオーバーフローが実際にCで未定義の動作を引き起こすことは事実です。つまり、オーバーフローのセマンティクスを完全に無視しても問題ありませんが、すべてのコンパイラーがそれを実行できるほど勇敢であるわけではありません。「Cは単なるより高いレベルのアセンブリ言語」の群衆から多くの批判を引き付けます。（GCCが厳密なエイリアシングセマンティクスに基づく最適化を導入したときに何が起こったか覚えていますか？）

歴史的に、GCCは、そのような抜本的なステップを踏むのに必要なものを備えたコンパイラーとしての地位を示してきましたが、他のコンパイラーは、言語で定義されていない場合でも、「ユーザーが意図した」動作を維持することを好むかもしれません。

今はそうです- 少なくとも、clangはします：

long long add_100k_signed(int *data, int arraySize)
{
    long long sum = 0;

    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            for (int i = 0; i < 100000; ++i)
                sum += data[c];
    return sum;
}

-O1でコンパイルして

add_100k_signed:                        # @add_100k_signed
        test    esi, esi
        jle     .LBB0_1
        mov     r9d, esi
        xor     r8d, r8d
        xor     esi, esi
        xor     eax, eax
.LBB0_4:                                # =>This Inner Loop Header: Depth=1
        movsxd  rdx, dword ptr [rdi + 4*rsi]
        imul    rcx, rdx, 100000
        cmp     rdx, 127
        cmovle  rcx, r8
        add     rax, rcx
        add     rsi, 1
        cmp     r9, rsi
        jne     .LBB0_4
        ret
.LBB0_1:
        xor     eax, eax
        ret

整数オーバーフローはそれとは何の関係もありません。未定義の動作を引き起こす整数オーバーフローがある場合、どちらの場合でも発生する可能性があります。これはの代わりに使用する同じ種類の関数intですlong：

int add_100k_signed(int *data, int arraySize)
{
    int sum = 0;

    for (int c = 0; c < arraySize; ++c)
        if (data[c] >= 128)
            for (int i = 0; i < 100000; ++i)
                sum += data[c];
    return sum;
}

-O1でコンパイルして

add_100k_signed:                        # @add_100k_signed
        test    esi, esi
        jle     .LBB0_1
        mov     r9d, esi
        xor     r8d, r8d
        xor     esi, esi
        xor     eax, eax
.LBB0_4:                                # =>This Inner Loop Header: Depth=1
        mov     edx, dword ptr [rdi + 4*rsi]
        imul    ecx, edx, 100000
        cmp     edx, 127
        cmovle  ecx, r8d
        add     eax, ecx
        add     rsi, 1
        cmp     r9, rsi
        jne     .LBB0_4
        ret
.LBB0_1:
        xor     eax, eax
        ret

この種の最適化には概念的な障壁があります。コンパイラの作成者は、強度の削減に多くの労力を費やしています。たとえば、乗算を加算とシフトに置き換えます。彼らは乗算が悪いと考えることに慣れています。したがって、一方を他方の方向に進めなければならないケースは、驚くほど直観に反するものです。したがって、誰もそれを実装することを考えていません。

コンパイラーの開発と保守を行う人は、作業に費やす時間とエネルギーに限りがあるため、一般に、ユーザーが最も気にかけていること、つまり、よく書かれたコードを高速コードに変換することに集中したいと考えています。彼らは、愚かなコードを高速なコードに変える方法を見つけることに時間を費やしたくないのです。それがコードレビューの目的です。高水準言語では、重要なアイデアを表現する「ばかげた」コードがあり、開発者がそれを速くするのに十分な時間をかけることができます。たとえば、ショートカットの森林破壊とストリームの融合により、Haskellプログラムは特定の種類の遅延で構築されますメモリを割り当てないタイトなループにコンパイルされるデータ構造を生成しました。しかし、そのようなインセンティブは、ループされた加算を乗算に変えることには適用されません。速くしたいなら