Loading article…
プロシージャ間最適化（IPO ）は、コンピュータプログラミングにおいて、頻繁に使用される多数の小規模または中規模の関数を含むプログラムのパフォーマンスを向上させるために使用されるコンパイラ技術の集合体です。IPOは、単一の関数やコードブロックではなく、プログラム全体を分析するという点で、他のコンパイラ最適化とは異なります。
IPOは、重複計算や非効率的なメモリ使用を削減または排除し、ループなどの反復処理を簡素化することを目的としています。ループ内で別のルーチンが呼び出された場合、IPO分析によってそのルーチンをインライン化するのが最適であると判断されることがあります。さらに、IPOはメモリレイアウトと局所性を向上させるためにルーチンの順序を変更することもあります。
IPOには、プログラム全体に適用される一般的なコンパイラ最適化も含まれる場合があります。例えば、実行されないコードを削除するデッドコード除去（DCE）などです。IPOはまた、定数のより適切な使用を確保するよう努めます。最新のコンパイラは、コンパイル時にIPOをオプションとして提供しています。実際のIPO処理は、人間が読めるソースコードから完成した実行可能バイナリプログラムの生成までのどの段階でも発生する可能性があります。
ファイル単位でコンパイルする言語の場合、翻訳単位（モジュールファイル）全体にわたる効果的なIPOを実現するには、プログラムの「エントリポイント」を把握し、プログラム全体の最適化（WPO）を実行する必要があります。多くの場合、これはリンク時最適化（LTO）パスとして実装されます。これは、リンカがプログラム全体を認識できるためです。
速度最適化の目的は、プログラムをできるだけ高速に実行することです。しかし、コンパイラがプログラムを正しく解析して、その動作、ましてやプログラマーの意図を正確に判断することは不可能です。これに対し、人間のプログラマーは明確な目的を持ってプログラムを作成し、その目的を達成するプログラムを開発しようとします。できれば、その過程で多くの思考を費やすことなく開発を進めたいと考えています。
可読性など様々な理由から、プログラムはしばしば、いくつかの一般的なケースを処理する複数のプロシージャに分割されます。しかし、各プロシージャの汎用性の高さは、特定の用途において無駄な労力を生み出す可能性があります。プロシージャ間最適化は、この無駄を削減するための試みです。
関数 を評価する手続きがありf(x)、 はf純粋関数であるとします。そして、コードが の結果を要求しf(6)、その後、f(6)再び を要求します。この 2 回目の評価はほぼ間違いなく不要です。結果は保存して後で参照できたはずです。この単純な最適化は、 の実装が不純になった瞬間に失敗しますf(x)。つまり、その実行には、6呼び出し間で変更された明示的な引数以外のパラメータへの参照や、ログへのメッセージ出力、評価回数のカウント、消費されたCPU時間の累積、関連するパラメータのその後の呼び出しを容易にするための内部テーブルの準備などの副作用が含まれます。これらの副作用を 2 回目の非評価によって失うことは許容できる場合もあれば、そうでない場合もあります。
より一般的に言えば、最適化とは別に、プロシージャを使用する2つ目の理由は、プロシージャを実行するたびに同じ結果、あるいはほぼ同じ結果を生み出すコードの重複を避けるためです。したがって、一般的な最適化のアプローチは、この逆の考え方に基づいています。つまり、特定のプロシージャの呼び出しの一部またはすべてを、適切なパラメータを置き換えた対応するコードに置き換えます。すると、コンパイラは結果を最適化しようとします。
全プログラム最適化（WPO ）とは、プログラム内のすべてのモジュールに関する情報を使用してプログラムをコンパイラが最適化することです。通常、最適化はモジュールごと、つまり「コンパイルランド」ごとに実行されます。しかし、このアプローチは、記述やテストが容易で、コンパイル自体のリソース消費も少ないという利点がある一方で、積極的なインライン化などの最適化の安全性について確証が得られないため、生成されるオブジェクトコードの意味を変えずに効率が向上することが判明した場合でも、これらの最適化を実行することはできません。
リンク時最適化（LTO ）とは、コンパイラがリンク時にプログラムに対して行うプログラム最適化の一種です。リンク時最適化は、プログラムをファイルごとにコンパイルしてからそれらのファイルをリンクするプログラミング言語（CやFortranなど）において重要であり、 Javaのジャストインタイムコンパイル（JIT）のように一度にすべてをリンクする方式とは異なります。
すべてのファイルが個別にオブジェクトファイルにコンパイルされた後、従来はコンパイラがオブジェクトファイルをリンク（マージ）して単一の実行可能ファイルを作成します。しかし、 GNU Compiler Collection（GCC）とLLVMで実装されているLTOでは、コンパイラは中間表現（IR）、つまりGIMPLEバイトコードまたはLLVMビットコードをダンプできるため、単一の実行可能ファイルを構成するさまざまなコンパイル単位を、最終的なリンク時に単一のモジュールとして最適化できます。これにより、プロシージャ間最適化の範囲がプログラム全体（正確には、リンク時に可視なすべて）にまで拡大されます。リンク時最適化により、コンパイラはプログラム全体にさまざまな形式のプロシージャ間最適化を適用できるため、より詳細な分析、より多くの最適化、そして最終的にはプログラムのパフォーマンス向上が可能になります。
実際には、LTO は必ずしもプログラム全体を最適化するわけではありません。ライブラリ関数、特に動的にリンクされた共有オブジェクトは、過剰な重複を避け、更新を可能にするために意図的に除外されます。静的リンクは、LTO の概念に自然とつながりますが、機械語のみのオブジェクト ファイルではなく、IR オブジェクトを含むライブラリ アーカイブでのみ機能します。[ 1 ]パフォーマンス上の懸念から、ユニット全体が常に直接使用されるとは限りません。プログラムは、GCC の WHOPR のような分割統治スタイルの LTO で分割される可能性があります。[ 2 ]そしてもちろん、構築中のプログラム自体がライブラリである場合、最適化は、DCE の一部としてそれらを削除しようとあまり努力することなく、外部で使用可能な (エクスポートされた) シンボルをすべて保持します。[ 1 ]
LTO がなくても、より限定的な WPO は可能です。これは GCC の-fwhole-programスイッチに例えられます。このモードでは、コンパイル中のモジュールがプログラム全体のエントリ ポイントを含んでいると GCC が想定するため、モジュール内の他のすべての関数は外部で使用されておらず、安全に最適化して削除できます。これは単一のモジュールにのみ適用されるため、プログラム全体を真に網羅することはできません。これは、リンカが外部で使用されているエントリ ポイントやシンボルについて GCC にフィードバックしない場合に便利な、1 つの大きなモジュールという意味で LTO と組み合わせることができます。[ 1 ]
ALGOLのような手続き型言語の場合、手続き間解析と最適化は1970年代初頭に商用化されたようです。IBMのPL/I最適化コンパイラは、手続き呼び出しと例外（PL/I用語では「条件付き」）の両方の副作用を理解するために手続き間解析を実行しました[ 3 ] 。また、 Fran Allenの論文[ 4 ] [ 5 ]でも同様のことが述べられています。APLプログラミング言語のコンパイル作業は必然的に手続き間でした[ 6 ] [ 7 ] 。
手続き間解析および最適化の手法は、1980年代から1990年代にかけて学術研究の対象となりました。そして1990年代初頭、Convex Computer Corporation （Convex C4用「アプリケーションコンパイラ」）とArdent（ Ardent Titan用コンパイラ）の両社からコンパイラが登場し、商用コンパイラの世界に再び姿を現しました。これらのコンパイラは、これらの技術が商用コンパイラで許容できるほど高速化できることを実証しました。その後、手続き間解析技術は、多くの商用および非商用システムに採用されるようになりました。
GNU Compiler Collection は、すべての最適化レベルで関数インライン化を行います。 では、これは-O1一度だけ呼び出されるものにのみ適用されます ( -finline-functions-once)。 では、-O2この制約は緩和されます ( -finline-functions)。デフォルトでは、これは単一ファイルのみの動作ですが、リンク時最適化で-fltoはプログラム全体になります。[ 1 ] Clangのコマンドラインインターフェイスは、オプションがないことを除けば、GCC のものと似ています-fwhole-program。[ 8 ]
LTO によって生成されるオブジェクト ファイルには、リンク時に解釈されるコンパイラ固有の中間表現(IR) が含まれています。静的ライブラリとの互換性を確保するため、新しいGNU リンカには、必要に応じてコンパイラがオブジェクト ファイルをマシン コード形式に変換できるようにする「リンカ プラグイン」インターフェースがあります。このプラグインは、LTO プロセス全般の推進にも役立ちます。あるいは、マシン コードと IR の両方を含む「ファット LTO」オブジェクトを生成することもできますが、これにはより多くのスペースが必要です。[ 1 ]
GCCとLLVM（clang）はどちらも様々なプログラミング言語からIRを生成できるため、言語の境界を越えてもリンク時IPOが実現可能です。これはCとC++で最もよく実証されていますが[ 9 ] 、LLVMはRustやその他のLLVMベースのコンパイラでもこれを可能にします[ 10 ] 。
GCC と Clang はデフォルトで最適化レベル 2 で IPO を実行します。ただし、LTO が無効になっている場合、IPO はオブジェクト ファイル内でのみ実行でき、非静的関数は決して削除できないため、最適化の度合いは制限されます。後者の問題には LTO 以外の解決策があります。-fwhole-programスイッチを使用すると、のみがmain()非静的、つまり外部から見えると想定できます。[ 11 ]
LTO 以外の別の手法として「関数セクション」（-ffunction-sectionsGCC および Clang の場合）があります。各関数をオブジェクト ファイル内の独自のセクションに配置することで、リンカは参照されていないセクションを削除することによって IR なしでデッド コード削除を実行できます (リンカ オプションを使用--gc-sections)。[ 12 ]変数に対しても同様のオプションが利用できますが、生成されるコードがはるかに悪くなります。
Intel C/C++ コンパイラは、プログラム全体の IPO を可能にします。単一ファイルに対してプロシージャ間最適化を有効にするフラグは であり-ip、プログラム内のすべてのファイルに対してプロシージャ間最適化を有効にするフラグは です-ipo。[ 13 ] [ 14 ]
Visual Studioに統合されているMSVCコンパイラは、プログラム全体に対するプロシージャ間最適化もサポートしています。[ 15 ]
プログラム全体のプロシージャ間最適化を可能にするコンパイラ非依存のインターフェースは、CMakeINTERPROCEDURAL_OPTIMIZATIONのプロパティを介して提供されます。[ 16 ]
リンク時の最適化では、プログラム全体が存在する必要はありません。プログラムがエクスポートするシンボルを必要としない場合、-flto と -fwhole-program を組み合わせて、プロシージャ間最適化ツールがより積極的な仮定を使用できるようにすることで、最適化の機会を改善できます。リンカー プラグインが有効な場合 (-fuse-linker-plugin を参照)、-fwhole-program の使用は不要です。