見出し画像

Mesa、LTOビルドを明示的に禁止

情報の灯台

長年の課題に終止符を打つ決断。Mesaがついに、LTO（Link-Time Optimization）でのビルドを禁止した。性能向上の代償は、誰も追えないバグだった。

2026年2月上旬、Mesaプロジェクトに重要なマージリクエストが統合された。Mesonビルドシステムが、LTOフラグを検出すると明確にエラーを出すようになる。

メッセージは端的だ。「Building Mesa with LTO is not supported. Please disable LTO for building Mesa.」

これは「お願い」から「禁止」への格上げである。

デバッグ不可能なバグとの戦い

LTOは、リンク時に全体最適化を行うコンパイラ技術だ。通常のコンパイルでは、ソースファイルを一つずつ機械語に変換し、最後にリンカがそれらを結合する。最適化はファイル単位でしか行えない。

LTOは違う。コンパイル時に機械語ではなく、コンパイラの中間表現（Intermediate Representation、IR）を生成する。GCCならGIMPLEバイトコード、LLVMならLLVMビットコードだ。そしてリンク時に、プログラム全体を一つの巨大なモジュールとして扱い、ファイルを跨いだ最適化を行う。

関数のインライン化、未使用コードの削除、メモリレイアウトの最適化。通常では不可能な最適化が可能になる。

結果、5〜15%の性能向上と、4〜5%のサイズ削減が期待できる。数字だけ見れば魅力的だ。

しかし、Mesaにとってこれは悪夢だった。

中間表現という呪い

問題の核心は、LTOが生成するバイナリの性質にある。

通常のバイナリなら、デバッガで関数の呼び出しを追跡できる。変数の値を確認できる。ブレークポイントを設定できる。だがLTOで最適化されたバイナリは違う。

リンク時の最適化によって、関数は別の場所にインライン化され、変数は最適化で消え、コードの構造は大きく変形する。元のソースコードとの対応関係は失われ、デバッグ情報は意味をなさなくなる。

これが「LTO performs heavy memory optimizations that break debugging」と言われる理由だ。

マージリクエストの説明文はこう述べている。「LTOは長年にわたり、ランダムで、デバッグ不可能なバグを引き起こしてきた」

バグが出ても、どこで何が起きているのか特定できない。スタックトレースは崩れ、変数の値は追えず、再現性も不安定。開発者は暗闇の中で手探りするしかなかった。

2018年のGentooのバグレポートには、LTOビルドでglFlushへの未定義参照エラーが発生した記録が残る。2019年には「GDMが起動しない」というバグが報告された。いずれも原因の特定は困難を極めた。

Mesaの開発チームは、長年この問題と向き合ってきた。LTO関連のバグレポートが来るたびに、彼らは同じ対応を繰り返した。

「WONTFIX please disable LTO instead」

直さない。代わりにLTOを無効にしてくれ。

あるGitHubのコメントには、こう書かれている。「Do NOT use LTO with Mesa. We don't support it and it is very likely to cause inexplicable issues.」

明確さという選択

今回の決定は、その方針を仕様として固定したものだ。

「ユーザーとパッケージャーに明確にしよう。これ以上、追跡不可能なバグレポートに時間を使わせないために」

開発リソースは有限だ。再現不可能なバグの報告に時間を奪われるより、実際に修正できる問題に注力したい。LTOを禁止することで、少なくとも「LTOが原因かもしれない」という不確実性は排除できる。

興味深いのは、完全に道を閉ざしたわけではない点だ。

どうしてもLTOを使いたい人のために、「allow-broken-lto」というオプションが用意された。名前が雄弁だ。「壊れたLTO」を許可する。つまり、これを使う者は、自己責任で不安定な領域に足を踏み入れることになる。

このオプション名には、開発者の本音が滲む。

性能か、安定性か

LTOをめぐる議論は、古くからある。

コミュニティでは、「Mesaに-march=nativeと-fltoを付けたが、性能向上は見られなかった」という報告もあれば、「MIPS32のソフトウェアレンダリングで50%の性能向上が見られた」という報告もある。効果は環境によってまちまちだ。

2016年のメーリングリストには、「glxgearsで1%の性能向上」という報告がある。一方で「-fltoはデバッグを不可能にする」という警告も添えられていた。

確実なのは、LTOによる最適化の恩恵を受けるのは、主にCPU性能が低い環境だということ。ハイエンドのマシンでは、元から十分速い。

一方、デバッグの困難さは、環境を選ばない。

Mesaの開発チームは、全体を見て判断した。一部のユーザーの性能向上より、全体の安定性とメンテナンス性を選んだ。曖昧な「推奨しません」ではなく、明確な「禁止」という形で意思を示した。

ArchLinuxのAURパッケージ管理者は、「arch-mesonがデフォルトでLTOを有効にする設定に同意できない」と述べている。Mesaに関しては、彼らの懸念が正しかった。

将来への扉

マージリクエストの最後には、こんな一文が添えられている。

「GCCやLLVM/ClangのLTOサポートが改善されれば、いつかこのチェックを見直せるかもしれない」

扉は閉じられたが、鍵はかかっていない。

コンパイラの技術が進化し、LTOがデバッグ可能なものになれば、再び検討の余地はある。デバッグ情報を保持したまま最適化する技術、中間表現から元のソースへの正確なマッピング、より安定したリンク時最適化。

それまでは、明確さと安定性を優先する。

ソフトウェア開発には、こういう判断がつきまとう。理想を追うのか、現実を取るのか。

Mesaは、現実を選んだ。

参照元

他参照

#Mesa #LTO #コンパイラ最適化

いいなと思ったら応援しよう！

情報の灯台 記事が役に立ったと感じていただけたら、チップで応援いただけると嬉しいです。いただいた支援は、より深い調査と分析のための時間に充てさせていただきます。灯台を灯し続けるための燃料になります。