最適化レベル-O3はg ++で危険ですか？

私はさまざまな情報源から聞いたことがあります（ほとんどが私の同僚からのものです）。 -O3 g ++のはどういうわけか「危険」であり、必要であることが証明されない限り一般に回避すべきであるとています。

これは本当ですか、もしそうなら、なぜですか？私だけに固執する必要があり-O2ますか？

gccの初期（2.8など）やegcsの時代には、redhat 2.96 -O3はかなりバグが多い場合がありました。しかし、これは10年以上前のことであり、-O3は他のレベルの最適化（バグが多い）と大差ありません。

ただし、言語のルール、特にコーナーケースに厳密に依存しているため、未定義の動作に依存するケースが明らかになる傾向があります。

個人的なメモとして、私は-O3を使用して金融部門で生産ソフトウェアを長年実行していますが、-O2を使用した場合には存在しなかったであろうバグにまだ遭遇していません。

人気の需要により、ここに追加：

-O3および特に-funroll-loops（-O3で有効にされていない）のような追加のフラグは、より多くのマシンコードが生成される原因になる場合があります。特定の状況下（例：非常に小さいL1命令キャッシュを持つCPU）では、これは、たとえば一部の内部ループのすべてのコードがL1Iに適合しなくなったためにスローダウンを引き起こす可能性があります。一般に、gccはそれほど多くのコードを生成しないようにかなり努力しますが、通常は一般的なケースを最適化するため、これが発生する可能性があります。これが特に発生しやすいオプション（ループの展開など）は通常-O3に含まれておらず、マンページで適宜マークされています。そのため、一般に-O3を使用して高速コードを生成し、適切な場合（たとえば、プロファイラーがL1Iミスを示す場合）に-O2または-Os（コードサイズの最適化を試みる）にフォールバックすることをお勧めします。

最適化を極端にしたい場合は、特定の最適化に関連するコストを--paramを介してgccで調整できます。さらに、gccは、これらの関数だけの最適化設定を制御する関数に属性を配置できるようになりました。そのため、1つの関数で-O3に問題がある場合（またはその関数のみに特別なフラグを試したい場合）、ファイル全体やプロジェクト全体をO2でコンパイルする必要はありません。

otoh -Ofastを使用するときは注意が必要なようです。

-Ofastは、すべての-O3最適化を有効にします。また、すべての標準準拠プログラムに有効ではない最適化も可能になります。

これにより、-O3は標準に完全に準拠することを目的としていると結論づけます。

私のややチェックした経験で-O3は、プログラム全体に適用すると、ほとんどの場合（に比べて-O2）遅くなります。これは、積極的なループのアンロールとインライン化がオンになり、プログラムが命令キャッシュに適合しなくなるためです。大規模なプログラムの場合、これは-O2、-Os！

の使用目的-O3は、プログラムをプロファイリングした後、これらの積極的なスペースと速度のトレードオフから実際に恩恵を受ける重要な内部ループを含む少数のファイルに手動で適用することです。GCCの新しいバージョンには、-O3最適化をホット関数に選択的に適用（IIUC）できるプロファイルに基づく最適化モードがあり、このプロセスを効果的に自動化します。

-O3オプションは、より低いレベルの '-O2'および '-O1'のすべての最適化に加えて、関数のインライン化など、よりコストのかかる最適化をオンにします。'-O3'最適化レベルは、結果として生成される実行可能ファイルの速度を上げる可能性がありますが、そのサイズを増やすこともできます。これらの最適化が好ましくない状況下では、このオプションは実際にプログラムを遅くする可能性があります。

はい、O3はバグが多いです。私はコンパイラの開発者であり、独自のソフトウェアをビルドするときに、O3がバグのあるSIMDアセンブリ命令を生成することによって引き起こされる明確で明白なgccバグを特定しました。私が見たところ、ほとんどの製品ソフトウェアにはO2が同梱されています。つまり、O3はテストやバグ修正に関する注意力を弱めます。

このように考えてください。O3はO2にさらに変換を追加し、O1にさらに変換を追加します。統計的に言えば、変換が多いほどバグが多くなります。これは、どのコンパイラにも当てはまります。

最近、私は最適化を使用して問題を経験しました g++。この問題は、PCIコマンドカードに関連しており、レジスタ（コマンドとデータ用）はメモリアドレスによって表されていました。私のドライバーは、物理アドレスをアプリケーション内のポインターにマップし、次のように機能する呼び出されたプロセスに渡しました。

unsigned int * pciMemory;
askDriverForMapping( & pciMemory );
...
pciMemory[ 0 ] = someCommandIdx;
pciMemory[ 0 ] = someCommandLength;
for ( int i = 0; i < sizeof( someCommand ); i++ )
    pciMemory[ 0 ] = someCommand[ i ];

カードは期待どおりに動作しませんでした。私はアセンブリを見たとき、私は、コンパイラだけ書いたことが理解someCommand[ the last ]へpciMemory、先行するすべての書き込みを省略し。

結論として、最適化を使用して正確かつ注意深く行います。