LLVM、ClangIRを既定でビルドするか議論

LLVMの開発者たちが、ClangがClangIRをすべてのビルドに組み込むべきかを議論しています。Erich Keane氏が「Enable ClangIR Build By Default」と題したRFCを2026年9月6日にLLVMのDiscourseフォーラムへ投稿しました。同じ日にPhoronixが報じた時点で、返信は34件に達していました。

提案は見出しが示すより狭いものです。組み込むことと、使うことは同じではありません。

実際に提案されていること

ClangIRはClangのための新しい中間表現です。中間表現とは、コンパイラがソースを解析してから機械語を出すまでの間、コードを保持しておく形式のことです。

Clangにはすでに1つ、LLVM IRがあります。ClangIRはそれより上位、つまり元の言語に近い層にあり、MLIRの上に作られています。上位にあるということは、LLVM IRが捨ててしまう情報、たとえばそのコードがどのC++の構文から来たのかを保てるということです。

コード自体はすでにupstreamに入っています。ただ既定のビルド構成に含まれていないため、ソースからClangをビルドするほとんどの人には届きません。

RFCが変えるのはその一点だけです。コード生成は、明示的に-fclangirを渡さない限り既存の経路を通ります。うっかりClangIRになる人はいません。

反対意見

スレッドを占める懸念は3つあり、どれもClangIRの出来を問うものではありません。

懸念	何が問題か
ビルド時間	2倍以上になるという見積もりもある
対応の穴	MicrosoftとWindows向けのターゲットが未対応
CIの費用	すべてのテスト機が、毎回長いビルドを負担する

損害を与えているのはビルド時間の数字です。MLIRをClangの既定の依存に加えると大量のコードが持ち込まれ、Clangをビルドする全員が、フラグを一度も渡さない人まで含めて、それをコンパイルすることになります。

この費用は均等には分かれません。ディストリビューションの保守担当がClangを一度ビルドするだけなら容易に吸収できます。ローカルで再ビルドを繰り返す貢献者や、プルリクエストごとに再ビルドするCI群は、繰り返し支払います。

それでも有効化したい理由

賛成の論拠は普及です。誰もコンパイルしない機能は、誰もテストしません。ClangIRを既定のビルドから外しておくことは、バグが、自ら有効にした少数の人にしか、しかもコードが入った後にしか現れないことを意味します。

既定で有効にすれば、ツリーの普通の一部になります。壊れたことが専用のbotではなく通常のCIで表に出るようになり、実験的な部品が静かに腐っていくのを防ぐ方法はそれです。

何も決まっていません。活発なスレッドを抱えたRFCであり、議論は方向性ではなく費用についてです。

これが開発者にとって意味すること

ソースからClangをビルドしているなら、結果よりスレッドを追ってください。ここで取引されているのはあなたのビルド時間であり、スレッドの数字はあくまで見積もりです。MLIRを含めた自分のビルドを一度測るほうが、フォーラムの数字より計画の材料になります。

LLVMをコンパイルするCIを運用しているなら、いま費用を見積もってください。プルリクエストごとの2倍は不便ではなく予算項目であり、この変更を最初に載せたリリースとともにやってきます。

Windowsのツールチェーンに関わっているなら、声を上げる場面です。RFCはMicrosoftターゲットの未対応をブロッカーとして挙げており、そうした重みづけが決まるのがRFCのスレッドです。オープンソースの世界では最近この種の意思決定の形式化が続いており、GNOMEによるRFCプロセスの起草からDebianのAI支援の貢献に関する投票まで例があります。

そしてパッケージマネージャからClangを使っているだけなら、いまのところ何も変わりません。コンパイラのバイナリが少し大きくなり、無視できるフラグが1つ増えるだけです。