-fno-strict-aliasingのパフォーマンスへの影響
GCC（または他のコンパイラで同等のもの）で-fno-strict-aliasingを指定したことによるパフォーマンスの低下を示す調査またはベンチマークのセットはありますか？
コンパイラーが異なれば、攻撃性のレベルも異なるため、コンパイラーごとに大きく異なります。 GCCはそれについてかなり積極的です。厳密なエイリアスを有効にすると、人間と「明らかに」同等であるポインタ（foo *a; bar *b = (bar *) a;など）はエイリアスできないと見なされます。これにより、非常に積極的な変換が可能になります。不注意に書かれたコードを明らかに壊す可能性があります。このため、AppleのGCCはデフォルトで厳密なエイリアシングを無効にします。
対照的に、LLVMはhave厳密なエイリアシングすらしていません。計画されている間、開発者は、他に同等性を判断できない場合のフォールバックケースとして実装する予定であると述べています。上記の例では、aとbが同等であると判断します。他の方法でそれらの関係を判別できない場合にのみ、タイプベースのエイリアシングを使用します。
私の経験では、厳密なエイリアシングのパフォーマンスへの影響は、ほとんどの場合、ループ不変のコードモーションに関係しています。この場合、型情報を使用して、ループ内のロードが反復される配列をエイリアシングできないことを証明できます。ループ。 YMMV。
私が経験からあなたに言えることは（PS3の大規模なプロジェクトでこれをテストしたことで、PowerPCは多くのレジスターのために実際にSA非常によく）恩恵を受けることができるアーキテクチャです） '一般的に非常にローカル（スコープに関して）で小さいことがわかります.20MBの実行可能ファイルでは、おそらく80kbの.textセクション（=コード）が削られ、これはすべて小さいスコープとループにありました。
このオプションを使用すると、生成されたコードを現在よりも少し軽量で最適化できます（1〜5％の範囲で考えてください）が、大きな結果は期待できません。したがって、-fno-strict-aliasingを使用した場合の影響は、パフォーマンスに大きな影響を与えることはないでしょう。とはいえ、-fno-strict-aliasingを必要とするコードを持つことは、せいぜい次善の状況です。
2004年に実施された調査へのリンクは次のとおりです。 http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1124&context=ecetr 特に、コードに対する厳密なエイリアシングの影響に関するパフォーマンス。図2.5は、3％から10％の相対的な改善を示しています。
パフォーマンス低下に関する研究者の説明：
アセンブリコードを調べたところ、劣化はレジスタ割り当てアルゴリズムの影響であることがわかりました。 GCCは、グラフ彩色レジスタアロケータ[2、3]を実装しています。厳密なエイリアシングを使用すると、変数の有効範囲が長くなり、レジスタ圧力が高くなり、「スピル」が発生します。より保守的なエイリアシングでは、同じ変数が（より短い）ライブ範囲の最後にもメモリ転送を発生させます。
[2] Peter Bergner、Peter Dahl、David Engebretsen、およびMatthew T. O’Keefe。干渉領域の流出による流出コードの最小化。プログラミング言語の設計と実装に関するSIGPLAN会議、287〜295ページ、1997年。
[3]プレストン・ブリッグス、キース・D・クーパー、リンダ・トルツォン。グラフ彩色レジスタ割り当ての改善。プログラミング言語とシステムに関するACMトランザクション、16（3）：428–455、1994年5月。