optimization - 最適化なしでコンパイルする理由はありますか?

Question

ほとんどのプロジェクトでは、プログラムの速度を劇的に向上させる可能性があるため、すべての-Oxプロジェクトの標準であると思われるフラグは表示されません。

コンパイルしない特定の理由はありますか、-Oxまたは gcc 以外の対応物ですか?

Answer 1

理由の 1 つは、デバッガーを使用してコードをステップ実行する場合です。最適化が有効になっている場合、ステートメントの順序を変更したり、見落としたりする可能性があり、プログラムの実行は、ソース コードの内容に順を追って実行する必要がありません。変数の値は最適化されているため、使用できない場合があります。したがって、プログラムをデバッガーで実行すると、そのプログラムが何を行っているかを判断するのは困難です。

最適化を避けるもう 1 つの理由は、プログラムで未定義の動作を使用しており、最適化によってプログラムが壊れる可能性があることです。(実際、これが最適化を使用する理由です。そのようなバグを見つけるためです。)

Answer 2

オブジェクト コードはソース コードのより直接的な翻訳になる傾向があるため、最適化されていないプログラムをデバッグする方がはるかに簡単です。最適化を有効にすると、コンパイラーはステートメントの順序を変更したり、複数の操作を 1 つにまとめてステートメントを完全に削除したりする場合があります。つまり、プログラム (またはコア ダンプ) をデバッグする場合、プログラム イメージ内の位置からソース コードの行への直接的なマッピングは行われません。

GCC 4.8は、パフォーマンスとデバッグ可能性の間の大きな妥協点である新しい最適化レベルを追加します。

新しい一般的な最適化レベル-Ogが導入されました。適切なレベルのランタイム パフォーマンスを提供しながら、高速なコンパイルと優れたデバッグ エクスペリエンスのニーズに対応します。開発の全体的な経験は、デフォルトの最適化レベルよりも優れているはずです-O0。

コンパイラを使用-Ogすると、デバッグが難しくならず、コンパイルに時間がかかりすぎない単純な最適化が行われるため、コードは完全に最適化されていないコードよりも優れたパフォーマンスを発揮しますが、それでもデバッグできます。

Answer 3

これにより、最適化なしでデバッグがより正確になります。

未使用の変数、冗長なステートメントはスキップされません。

Answer 4

少し古いプロジェクトでは、多くの印刷ステートメントを含むすべてのテストがデバッグ ビルドで行われました。顧客に提供される最終ビルドについては、タイミングに関連する問題が発生する可能性があるため (gcc の完全な最適化オプションを使用して) あまりテストされていないリテール ビルドを使用しないことが決定されました (実際には、特定の理由により、欠陥の検出が隠されています)。デバッグ ビルドのタイミング)、および顧客が現在の動作速度に十分満足しているためです。

私の現在のプロジェクトでは、多くのコードを ROM に配置する必要があります (最初はすべて)。その後、デッド コードを削除したくないのは明らかです。 rom コード、ram のスペース要件を削減します。

また、デフォルトは何ですか？スペースを最適化するか、それとも実行時間を最適化しますか? 選ばないことが唯一の正しい選択です。