問題タブ [auto-vectorization]

新しい RyuJIT コンパイラはベクトル (SIMD) CPU 命令を生成しますか? また、いつ生成しますか?

補足: System.Numerics 名前空間には、ネイティブ コードに直接コンパイルするかどうかにかかわらず、CPU、CLR バージョン、JITer バージョンに応じて SIMD 命令を生成する場合と生成しない場合がある Vector 操作を明示的に使用できる型が含まれています。この質問は、非ベクター コード (C# や F# など) がいつ SIMD 命令を生成するかに関するものです。

gcc auto-vectorize documentationから例 4 の単純化されたバージョンをベクトル化しようとしています。私の人生では、それを行う方法がわかりません。

gcc -o apps/craft_dbsplit.o -c -Wall -g -ggdb -O3 -msse2 -funsafe-math-optimizations -ffast-math -ftree-vectorize -ftree-vectorizer-verbose= で gcc 4.7.2 を実行しています。 5 -funsafe-loop-optimizations -std=c99

そして、次のように応答します。

現在、次の 2 つのフラグ設定を使用して、spec2000 アート ベンチマークをコンパイルしています。

1. -Ofast -m32 -march=native
2. -Ofast -m32 -march=native -fno-tree-vectorize

2 番目の設定は、ベクトライザーを無効にするだけです。しかし、2 つの設定の objdump を確認すると、どちらも、 などvmovapdのパックされた命令が表示されます。vxorpd

誰でも説明できますか？ありがとう。

飽和算術演算を行う for ループがいくつかあります。例えば：

私の場合の飽和加算の実装は次のとおりです。

x86 には、このループの完璧な解決策となる可能性のある組み込みの paddsat があることがわかりました。コードは自動ベクトル化されますが、コードに従って複数の操作を組み合わせています。自動ベクトライザーがaddsat操作の一致を正しく検出するこのループを記述する最良の方法を知りたいです。

ベクトル構造は次のとおりです。

使用するコンパイラは clang 3.8 で、コードは AVX2 Haswell x86-64 アーキテクチャ用にコンパイルされています。

最初に#pragma omp simdディレクティブの効果を調査したところ、単純な for ループのベクトル化に関連する、説明できない動作に遭遇しました。次のコード サンプルは、-O3ディレクティブが適用され、x86 アーキテクチャを使用している場合、この優れたコンパイラ エクスプローラーでテストできます。

次の観察の背後にある論理を説明してくれる人はいますか?

私が困惑しているのは、l1 と l3 の両方が 32 の倍数であることが保証されていないにもかかわらず、ベクトル化されたコードを生成することです。他のすべての長さはベクトル化されたコードを生成しませんが、32 の倍数にする必要があります。これには理由がありますか?

余談ですが、#pragma omp simd ディレクティブを使用しても、実際には何も変わりません。

編集: さらに調査した結果、インデックス タイプが size_t の場合 (境界操作も必要ない場合)、動作の違いはなくなります。これは、ベクトル化されたコードが生成されることを意味します。

ループのベクトル化がインデックスの種類に大きく依存する理由を誰かが知っているなら、もっと知りたいです!

Edit2、Mark Lakata のおかげで、実際には O3 が必要です

g++ 5.4 ( ) で自動ベクトル化を使用しようとしています-ftree-vectorize。以下のコードの配列バージョンが原因で、コンパイラーが内部ループでベクトル化の機会を逃し、ポインター バージョンと比較してパフォーマンスが大幅に異なることに気付きました。この場合、コンパイラを支援するためにできることはありますか?