インライン化と関数間最適化（LTO）

なぜインライン化が最適化の要なのか

関数呼び出しには、引数の準備・スタックフレームの確保・制御の移動・戻り値の受け渡しという固定的なコストが伴います。しかしインライン化（inlining）の真価は、この呼び出しオーバーヘッドの除去そのものではありません。本質は、呼び出し先の本体を呼び出し側へ展開することで、関数の境界というデータフローの壁が消える点にあります。

int square(int x) { return x * x; }
int f() { return square(3) + 1; }

square(3) をインライン展開すると f() は return 3 * 3 + 1 となり、ここで初めて定数伝播が 9 + 1、さらに 10 へと畳み込めます。展開前は引数 x が呼び出し側で何になるかが見えず、これらの最適化は関数の壁で止まっていました。インライン化はSSA形式とコンパイラ最適化で扱う定数伝播・デッドコード除去・共通部分式除去といったスカラ最適化を駆動する触媒であり、これがコンパイラがインライン化を最重要パスの一つに据える理由です。

コスト/利益モデルと閾値判断

すべての呼び出しを展開すればよいわけではありません。展開はコードを複製するため、無制限に行うと総コードサイズが膨張し、命令キャッシュ（I-cache）のミスが増えてかえって遅くなる——これがインライン化の中心的なトレードオフです。そこでコンパイラは各呼び出し地点について、利益とコストを見積もるコスト/利益モデルで判断します。

実装上は、本体を擬似命令単位でコスト化し、展開で消える命令（定数化される分岐や引数移動）を「ボーナス」として差し引いた純コストを閾値と比較します。例えば本体サイズが閾値未満なら展開、というのが素朴な形です（不等号でいえば「コスト < 閾値」のとき展開）。最適化レベルが上がるほど閾値は緩み、-Os/-Oz のようなサイズ優先では厳しくなります。

直接呼び出しと間接呼び出し — インライン化の前提

インライン化はどの関数本体を展開するかが静的に確定して初めて行えます。直接呼び出し（コンパイル時に呼び先が分かる）はそのまま候補になりますが、関数ポインタ経由や動的ディスパッチとvtableによる仮想呼び出しは、実行時まで呼び先が定まらないためそのままではインライン化できません。オブジェクト指向コードで仮想呼び出しが多用されると、関数の壁が解けず最適化が連鎖しない——この障壁を崩すのが次のデバート化です。

デバート化（devirtualization）

デバート化（devirtualization）は、仮想呼び出し（間接呼び出し）を直接呼び出しに変換する最適化です。直呼びに変われば、その先をインライン化できるようになります。手法は確実性の度合いで段階的です。

• 投機なしのデバート化：型解析で呼び先が一意に確定する場合。例えばあるクラスが派生を持たない（final 宣言や全プログラム解析で派生不在が判明）とき、その型のメソッド呼び出しは一意なので直呼びに置換できます。クラス階層解析（CHA: Class Hierarchy Analysis）がこれを支えます。
• 投機的デバート化（speculative）：プロファイルや型推測から「ほぼこの型」と予測し、ガード（実行時の型チェック）付きで直呼び＋インライン化を挿入し、予測外れ時のみ元の仮想呼び出しへ落とすコードを残します。

// 仮想呼び出し  obj.draw()  を、Circle が支配的という推測でこう展開
if (obj.type == Circle) {
    /* Circle::draw の本体をインライン展開 */
} else {
    obj.draw();   // フォールバック（本来の間接呼び出し）
}

投機的デバート化はJITコンパイルとプロファイル誘導最適化の内部で中核を成します。実行時に観測した受信側の型分布（モノモーフィック＝単一型なら特に有効）を使い、ガードが外れたら脱最適化（deoptimization）で安全に戻す——この組み合わせが動的言語の高速化の鍵です。静的コンパイラでもプロファイル誘導最適化（PGO）で同様の判断が可能です。

翻訳単位の壁とLTOの必要性

ここまでの最適化は、コンパイラが呼び先の本体を見られることが前提でした。ところがC/C++などの分割コンパイルでは、各ソースファイルが独立した**翻訳単位（translation unit）**としてオブジェクトファイルにコンパイルされ、別ファイルで定義された関数の中身はコンパイル時に見えません。

// util.c
int helper(int x) { return x * x + 1; }
// main.c  ——  helper の宣言だけ見え、本体は不可視
int main() { return helper(7); }

main.c のコンパイル時、helper は宣言（プロトタイプ）しか見えないため、インライン化も定数伝播もできず、通常の呼び出し規約に従った関数呼び出しが残ります。最適化は翻訳単位の内側で頭打ちになる——これが関数間最適化の壁です。

LTO — リンク時最適化の仕組み

LTO（Link-Time Optimization、リンク時最適化）は、この壁をコンパイルとリンクの役割分担を作り替えることで越えます。

1. IRの埋め込み：各翻訳単位を機械語に落とし切らず、コンパイラの中間表現（AST と IRでいうIR。LLVMならbitcode、GCCならGIMPLE）をオブジェクトファイルに格納します。
2. リンク時の統合：リンカ（プラグイン経由）が全オブジェクトのIRをかき集め、全プログラムを一つの大きなIRとして再構成します。ここで初めて main から helper の本体が見えます。
3. 関数間最適化と再生成：統合IR上で跨ぎインライン化・デバート化・関数間定数伝播・未使用関数の除去などを行い、その後で機械語を生成します。

これにより helper(7) は翻訳単位を越えてインライン展開され、49 + 1 = 50 まで畳み込めます。LTOの効果は「翻訳単位の壁を取り払って、これまでの全最適化を全プログラム規模で再実行する」点に集約されます。

まとめ

インライン化の本質は呼び出しコストの除去ではなく、関数の壁を壊して定数伝播・デッドコード除去などのスカラ最適化を連鎖的に駆動することにあります。どこを展開するかはコスト/利益モデルで決まり、本体サイズ・呼び出し頻度・定数引数・コードサイズ膨張（I-cache圧迫）を閾値で天秤にかけます。仮想呼び出しはそのままでは展開できないため、デバート化で直呼びへ変換し（投機的なら実行時ガード付きで）インライン化の前提を整えます。そして翻訳単位の壁はLTOがIRをリンク時に統合することで越え、跨ぎインライン化や関数間最適化を全プログラム規模で可能にします——これが現代コンパイラ最適化の最終段です。