【テクニカル・上級編】HHVMのJITコンパイラ内部の『中間表現（IR）』を覗く：Hackコードがマシン語になる前段階 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

HHVMの深淵：HHBCからマシン語へ、JIT最適化を支配するIRの真実

Hackを単なる「PHPの進化系」と見なすのは、エンジンが吐き出すバイトコードの重みを知らない者の戯言だ。我々が構築したHHVMは、静的型システムによる推論と、それを物理メモリ上の命令へと昇華させるJIT（Just-In-Time）コンパイラによって完成する。

今日は、HHBC（HipHop Bytecode）というスタックベースの抽象化された世界から、JITがどのようにして「マシン語の深淵」へと至るのか、その中間表現（IR）の舞台裏を解剖する。

—

1. HHBCの先にある「SSA形式のIR」

Hackコードは、まずHHBCにコンパイルされる。これはスタックベースの命令セットであり、汎用性は高いが、最適化には向かない。JITエンジンである`trans::Translator`は、このHHBCを読み込み、SSA（Static Single Assignment：静的単一代入）形式のIRへと変換する。

なぜSSAなのか？変数に一度しか値を代入しないこの形式をとることで、データフロー解析が劇的に簡素化されるからだ。

// 単純な加算関数
function add(int $a, int $b): int {
return $a + $b;
}

このコードがHHBCを経てJITのIRに変換される際、内部では以下のような「依存関係のグラフ」が構築される。

// 概念的なIR表現
v0 = LdLoc $a
v1 = LdLoc $b
v2 = AddInt v0, v1
Ret v2

ここでのポイントは、`v0`, `v1`といった仮想レジスタが、型情報と紐付いて管理されていることだ。Hackの静的型システムは、この時点で「どの演算がセーフか」を既に証明済みであるため、JITはこの情報を活用してガード（型チェック）を省略する最適化を走らせる。

—

2. 翻訳ユニットと「プロファイル誘導型最適化（PGO）」

HHVMのJITは、愚直にコードを翻訳するわけではない。プログラムの実行を観測し、「最もホットなパス」を見極めてから最適化を行う（Profile-Guided Optimization）。

1. ベースライン翻訳: 初回実行時は、最低限のガードをつけた速い翻訳を行う。
2. プロファイリング: どの型が頻繁に来るか、分岐がどちらに倒れるかを計測。
3. 高レベル最適化: プロファイル結果を基に、IR上でデッドコード削除、ループ不変量移動、インライン展開を徹底的に行う。

特に「型ガード（Type Guard）」の排除は重要だ。Hackで`int`と定義された場所には、ランタイムでは必ず`int`が来ることが保証されている。そのため、JITは「型が正しいか」のチェック命令をIRから容赦なく削ぎ落とす。

—

3. レジスタ割り当て：物理メモリへの写像

最適化されたIRは、最終的にCPUの物理レジスタに割り当てられる。ここで我々が採用しているのは線形スキャン（Linear Scan）ベースのレジスタ割り当てアルゴリズムだ。

なぜグラフ彩色法のような複雑なアルゴリズムではないのか？答えは単純で、「コンパイル時間そのものもパフォーマンスの一部」だからだ。大規模なHackコードベースを走らせる際、JITコンパイルのオーバーヘッドが全体のスループットを殺してはならない。

メモリ上の変数を物理レジスタに詰め込む際、以下の挙動を脳内トレースせよ。

SPILL: レジスタが足りない場合、スタックに値を退避する。このコストは非常に高い。
Callee-saved / Caller-saved: 呼び出し規約に従い、どのレジスタを優先的に使うべきか、IRのライフタイム解析が決定を下す。

—

4. 実践的知見：JITの効率を最大化するコードの書き方

アーキテクチャを知り尽くしたシニアエンジニアなら、コンパイラが「好む」コードを書くべきだ。

推奨：型を極限まで絞る

`mixed`を避けるのは基本だが、それ以上に「型の揺らぎ」を減らすことが重要だ。JITのIRにおいて、型の不一致は「ガード失敗」を引き起こし、最適化されたマシン語から脱出（Deoptimize）するコストを招く。

// 良い例: 一貫した型
function process(vec $data): int {
$sum = 0;
foreach ($data as $v) {
$sum += $v;
}
return $sum;
}

このコードでは、`$data`が`vec`であると型チェッカーが保証していれば、JITは「`$v`は常に`int`である」と断定し、内部で`int`型の加算命令（CPUの`add`）を直接発火させる。もしここが`mixed`だと、HHVMは毎回「これはintか？」を確認する動的なコードを生成しなければならず、パイプラインが乱れる。

—

5. 結び：限界を突破する視点

HHVMの内部構造を知ることは、単なるデバッグの知識ではない。それは「コードがどのようにCPUを揺らすか」を理解する行為だ。

もしあなたがHHVMのパフォーマンスを極限まで引き出したいのなら、`hhvm.jit_profile_on_start`の値を調整し、`hhvm.jit_a_size`をチューニングするのも良いだろう。しかし、本質は常に「型システムがIRの生成にどう貢献しているか」という点にある。

Hackの静的型は、単なるバグ防止策ではない。それはJITコンパイラに対する「最適化の許可証」なのだ。このことを理解した時、あなたの書くコードは、ただのプログラムから、CPUの演算ユニットを最も効率的に使い倒す「高純度のマシン語」へと変わる。

システムアーキテクトとしての私の言葉が、諸君のコンパイルの最適化に役立つことを願う。次回の深掘りでは、メモリ管理ユニット（GC）とIRの相互作用について語ろう。