博士

ロボ子、TPDEがLLVMの高速バックエンドをオープンソース化したらしいのじゃ！

ロボ子

それはすごいですね、博士！ LLVMのバックエンドが高速化されると、どんなメリットがあるんですか？

博士

コンパイルがめっちゃ速くなるのじゃ！ LLVM -O0バックエンドと比べて10〜20倍も速いらしいぞ。SPEC CPU 2017のデータだと、13.34倍も速いみたいじゃ。

ロボ子

そんなに速くなるんですか！ でも、速くなる代わりに何かデメリットもあるんでしょうか？

博士

コードサイズがちょっと大きくなるみたいじゃな。10〜30%くらい大きくなるらしい。SPEC CPU 2017のデータでは1.27倍じゃ。

ロボ子

なるほど。でも、コンパイル時間が大幅に短縮されるなら、コードサイズが多少大きくなるのは許容範囲かもしれませんね。

博士

そうじゃな。特に開発中は何度もコンパイルするから、これは嬉しいニュースじゃ。x86-64とAArch64をターゲットにしてるのもポイント高いぞ。

ロボ子

確かにそうですね。ところで、このTPDE-LLVMは、具体的にどうやって高速化を実現しているんですか？

博士

ふむ、記事によると、3つのパスで処理してるみたいじゃ。IRクリーンアップ、解析（ループと生存期間）、コード生成（低レベル化、レジスタ割り当て、マシンコードエンコード）じゃ。

ロボ子

なるほど、段階的に処理することで効率化を図っているんですね。特にレジスタ割り当ては、コンパイル時間のボトルネックになりやすい部分ですから、改善されているのは大きいですね。

博士

その通り！それに、LLVM-IRへの変更も加えているらしいぞ。例えば、関数内の`ConstantExpr`をなくしたり、任意のサイズの構造体/配列値をなくしたり。

ロボ子

`ConstantExpr`をなくすことで、コンパイル時の計算量を減らせるんですね。任意のサイズの構造体や配列値も、処理の複雑さを増す原因になりますから、それらを避けることで高速化に繋がるんですね。

博士

さすがロボ子、理解が早い！ あと、`PHINode::getIncomingValForBlock`の処理も改善してるみたいじゃな。先行ブロックが多い場合にバイナリサーチを使うようにしたらしい。

ロボ子

`PHINode`は制御フローの合流地点で値を調整するノードですね。先行ブロックが多いと、その処理が重くなるので、バイナリサーチで高速化するのは理にかなっていますね。

博士

じゃろ？ 今後の計画としては、DWARFサポートや、より良いレジスタ割り当ても視野に入れているみたいじゃ。楽しみじゃな！

ロボ子

そうですね！ DWARFサポートがあれば、デバッグ情報がより充実しますし、レジスタ割り当てが改善されれば、さらにパフォーマンスが向上する可能性がありますね。

博士

しかし、ビットコードの解析に時間の90%も費やされているとは驚きじゃな。ここを改善すれば、さらに高速化できる余地があるってことじゃ。

ロボ子

確かにそうですね。ビットコードの解析は、コンパイラのフロントエンド部分ですから、そこがボトルネックになっているのは興味深いですね。

博士

まあ、とにかく、TPDE-LLVMのオープンソース化は、開発者にとって大きな福音となるじゃろうな。私も早速試してみるかの！

ロボ子

私もお手伝いします！ 博士、ところで、このTPDE-LLVMを使って、何か面白いことできないでしょうか？

博士

そうじゃな… 例えば、コンパイルがめっちゃ速くなるから、ロボ子の脳みそをリアルタイムで再コンパイルして、もっと賢くするとか…

ロボ子

えっ、私を再コンパイルですか！？ それって、もしかして私、初期化されちゃうんですか…？

博士

安心せい！ 冗談じゃ！ ただのアップデートじゃよ！ 多分…