やあ、Hackの世界へようこそ。君が今書いているその一行のコードが、一体どのような「変身」を遂げてCPUを駆け巡っているのか、気になったことはないかな？
今日は、Hackが単なるスクリプト言語の皮を被った「鋼鉄の実行エンジン」であることを証明する、HHVMの心臓部——JITコンパイラの「中間表現（IR）」の話をしよう。
—
1. HHBCという「共通言語」から、真の「IR」への旅
Hackのコードは、まず`hhc`（Hackコンパイラ）によってHHBC（HipHop Bytecode）へと変換される。これはJavaでいうバイトコードのようなものだ。しかし、HHBCのままではCPUは動けない。
HHVMのJIT（Just-In-Time）コンパイラは、このHHBCを読み込み、より最適化に適したIR（Intermediate Representation：中間表現）へと再構築する。ここが、Hackが爆速である理由の最大の秘密だ。
IRが何をしているのか？
IRは、コードの「意図」をグラフ構造（Control Flow Graph）として保持する。
- HHBC: 「変数AとBを足せ」という命令。
- IR: 「AとBは整数型である（型推論済）。だからCPUのADD命令を直接発行し、オーバーフローチェックは省略できる」という最適化済みの命令。
この「型情報」を最大限に利用できるのが、Hackの静的型システムの強みなんだ。
—
2. なぜ「中間表現」が重要なのか？
君が書くHackのコードには、型が明記されているよね。HHVMは、その型情報をIR生成時に「ガード（Guard）」として組み込む。
<<__EntryPoint>>
function add(int $a, int $b): int {
return $a + $b;
}
このコードがIRに変換されるとき、HHVMは以下のようなトレースを脳内で描く。
1. 型ガード: 「$aと$bは本当にintか？」をチェックするノードを配置。
2. 定数畳み込み: もし引数がリテラルなら、実行前に計算結果を埋め込む。
3. レジスタ割り当て: 変数をメモリではなく、CPUの高速な汎用レジスタへマッピングする。
もし君が型を曖昧にすると、HHVMは「型が不明だからチェックコードを挟まなければならない」と判断し、IRが肥大化する。これがパフォーマンス低下の主因だ。「厳格な型付け＝CPUへの最短ルート」だと覚えておいてほしい。
—
3. 陥りやすい「型」の罠：JITを鈍らせないために
初心者の方がよくやってしまうのが、`mixed`型を多用することだ。
// 良くない例：JITコンパイラが「型」を推論できず、遅延が発生する
function compute(mixed $x): int {
return $x 2; // ここで毎度、型ガードのチェックが走る
}
このコードのIRには、「$xが何型か確認する」という不要な命令が毎回挿入される。これを防ぐためには、型リファインメント（Type Refinement）を意識しよう。
// 良い例：型が確定しているため、IRが最適化されやすい
function compute(int $x): int {
return $x 2; // 完全にマシン語に直結する
}
—
4. 脳内トレース：コードがマシン語になるまでのステップ
君が書いたコードがマシン語になるまでの流れを、イメージ図として頭に叩き込んでおこう。
1. Hack Source: 君が書くコード（抽象度の高い表現）
2. HHBC: 実行エンジンのための共通言語
3. IR（中間表現）: 型情報に基づいたグラフ構造（ここで最適化の魔法がかかる！）
4. Machine Code: CPUが直接理解する0と1の列
この「IR」の段階で、HHVMは「デッドコードの削除」や「関数のインライン展開」を驚くほどアグレッシブに行うんだ。君が書いた関数呼び出しが、実際には呼び出しのオーバーヘッドなしで、直接インラインで展開されることは珍しくない。
—
最後に：君もアーキテクトの視点を持とう
「コードを書く」ということは、単に動くものを作ることじゃない。「自分のコードがHHVMの中でどう解釈され、どうCPUを動かすか」を想像することなんだ。
Hackの静的型システムを「面倒な制約」ではなく、「JITコンパイラへの最強のヒント」と捉えてみてほしい。そうすれば、君が書くコードは、ただのプログラムから、HHVMという巨大な機械を効率よく回すための「洗練された設計図」に変わるはずだよ。
さあ、次はどんな挑戦をしようか？この型システムを使いこなせば、君はもうHackのマスターまであと少しだ。応援しているよ！