C++コンパイラの最適化におけるgotoの影響 質問する

C++コンパイラの最適化におけるgotoの影響 質問する

goto最新の C++ コンパイラを使用するとパフォーマンス上の利点や欠点は何ですか?

私は C++ コード ジェネレーターを作成していますが、 を使用するとgoto作成が簡単になります。結果の C++ ファイルには誰も触れないので、「goto は悪い」と私を責めないでください。利点としては、一時変数の使用を節約できます。

純粋にコンパイラの最適化の観点から、gotoがコンパイラの最適化にどのような影響を与えるのか気になります。コードがもっと早くもっとゆっくり、または一般的に変化なし一時変数/フラグを使用する場合と比較してパフォーマンスが向上します。

ベストアンサー1

影響を受けるコンパイラの部分は、フロー グラフで機能します。厳密に移植可能なコードを記述している限り、特定のフロー グラフを作成するために使用する構文は通常無関係です。実際のステートメントの代わりにwhileを使用してループのようなものを作成した場合、ループの構文を使用した場合と同じフロー グラフは生成されません。ただし、移植不可能なコードを使用する場合、最新のコンパイラでは、ループに注釈を追加して、ループが実行されるかどうかを予測できます。コンパイラによっては、 を使用してその追加情報を複製できる場合とできない場合があります(ただし、ループの注釈があるコンパイラのほとんどはステートメントの注釈も持っているため、制御するにまたは を使用すると、対応するループに同様の注釈がある場合と同じ効果が得られます)。gotowhilewhilegotoiflikely takenlikely not takenifgoto

ただし、gotoグローバルの値に応じて、条件付きでループの途中に直接ジャンプするなど、通常のフロー制御ステートメント (ループ、スイッチなど) では生成できないフロー グラフを生成することは可能です。このような場合、縮小不可能なフロー グラフが生成される可能性があり、その場合、コンパイラがコードを最適化する能力が制限されることがよくあります。

言い換えれば、たとえば、通常の、for、などで記述されたコードを、同じ構造を保持したまま、すべてのケースで を使用するように変換した場合、ほぼすべての比較的新しいコンパイラは、どちらの方法でも本質的に同一のコードを生成する可能性があります。ただし、 を使用した場合、数十年前に私が調べた一部の FORTRAN のように、スパゲッティの混乱を生成すると、コンパイラはおそらくそれを処理できないでしょう。whileswitchgotogoto

おすすめ記事