こんにちは。開発現場の底上げを担うテックリードの皆さん。
日々のコーディングで「なぜコンパイラはこの些細な冗長性を消し去ってくれないのか」「俺が書いた意図通りのレジスタ割り当てやループアンロールを、なぜ安全マージンをとって日和るのか」と、Cコンパイラの最適化器（Optimizer）の前に歯痒さを覚えたことはないだろうか。
LLVM/Clangエコシステムは、単なる「Cをバイナリにする翻訳機」ではない。フロントエンド（Clang）とバックエンド（LLVM Code Generator）の間にLLVM Intermediate Representation (IR) / Bitcodeという強固な共通言語（抽象構文木の極限）を挟むことで、コンパイラパイプラインを完全にモジュール化している。
今回は、Clangという「フロントエンドの神殿」をバイパスし、LLVM Bitcodeを直接抽出・操作し、`opt`コマンドによって最適化パイプライン（Pass）をハックする実務的アプローチを解説する。これをモノにすれば、コンパイラの「自動最適化のブラックボックス」を完全に手中に収め、既存のCコードから極限のパフォーマンスを引き出すことが可能になる。
—
1. なぜClangフロントエンドをスキップするのか？（アーキテクチャの裏側）
通常のビルドプロセスは以下の通りだ。
[ C Source ] -> ( Clang Frontend ) -> [ LLVM IR ] -> ( opt / llc ) -> [ Machine Code ]
通常、`clang -O3`を実行すると、Clangは内部でLLVM IRを生成し、一連の標準最適化パス（`-O3`に紐づくループベクトル化、インライン展開、Dead Code Eliminationなど）を自動適用してアセンブリに落とし込む。
しかし、このプロセスには限界がある。
1. コンパイラのヒューリスティクスへの依存: コンパイラは「安全第一」で作られているため、未定義動作（Undefined Behavior）の境界線上で過剰な防衛コードを挟む。
2. パス順序（Pass Pipeline）の硬直性: 標準の`-O3`が適用するパスの順序は汎用であり、特定ドメインのアルゴリズム（例：暗号処理、高頻度トレーディングのパケットパーサ）にとって最適とは限らない。
ここで、「ClangでIRまで一旦止め、人間が（あるいはカスタムスクリプトが）Bitcodeを直接いじり、それをバックエンドに渡す」というワークフローが強力な武器になる。
—
2. 実践：LLVM Bitcodeの抽出と手動最適化パイプラインの構築
百聞は一見に如かず。実際に手を動かして、LLVM Bitcodeを直接操作してみよう。ターゲットとして、ポインタのエイリアシング（Aliasing）が原因でコンパイラが最適化を日和る典型的なコードを用意した。
対象コード (`target.c`)
include
// restrictキーワードを使ってもコンパイラが構造体内部まで追いにくいケースを想定
void process_data(uint32_T restrict dst, const uint32_T restrict src, int n) {
for (int i = 0; i < n; i++) {
// 意図的に冗長なメモリアクセスと計算を挟む
dst[i] = src[i] 2 + 5;
dst[i] = dst[i] src[i]; // 前の計算結果を再利用せず、再度src[i]を読みに行かせたい意図としよう（あるいは逆にレジスタに保持させたい）
}
}
ステップ 1: Clangを止め、LLVM Bitcode (.bc) を生成する
`-emit-llvm` フラグを使い、機械語ではなくLLVMバイトコードを出力させる。可読性を高めるためにテキスト形式（`.ll`）も同時に出力しておくとデバッグしやすい。
バイナリ形式のLLVM Bitcode (.bc) を生成
clang -O0 -emit-llvm -c target.c -o target.bc
人間が読めるテキスト形式のLLVM IR (.ll) に変換（中身の確認用）
llvm-dis target.bc -o target.ll
生成された `target.ll` を覗くと、SSA（静的単一代入）形式で書かれた低レイヤの仮想アセンブリが広がっている。ここに、人間サニタイズを施す。
ステップ 2: `opt` コマンドによる最適化パスの個別ハック
通常、`opt` はLLVMの最適化ツールだ。標準のパスバンドルを一括適用するだけでなく、特定のパスだけを、特定の順序で適用できる。
例えば、メモリアクセスの冗長性を排除する `gvn`（Global Value Numbering）パスと、不要な指示を削る `deadargelim` パスを明示的に、かつ独自の順序で適用してみる。
GVN (Global Value Numbering) と 冗長コード除去 (DCE) パスを強制適用
opt -passes=’gvn,dce’ target.bc -o target_opt.bc
さらに、もしループのアンロール（Loop Unrolling）をしつこく強制したい場合は、専用のパスを注入できる。
ループアンロールを強制（係数を指定：カウント4）
opt -passes=’loop-unroll(unroll-count=4)’ target_opt.bc -o target_unrolled.bc
ステップ 3: 最適化済み Bitcode からオブジェクトファイルを生成
最適化が終わった Bitcode (`target_unrolled.bc`) を、最終的にバックエンドコンパイラ `llc` を使ってネイティブのオブジェクトファイルにコンパイルする。
LLVMバックエンドでネイティブアセンブリに変換
llc -filetype=obj target_unrolled.bc -o target.o
リンクして実行ファイルへ
clang target.o -o target_exec
この一連の流れをメイクファイルやCI/CDパイプラインに組み込むことで、「コンパイラのデフォルトの機嫌に左右されない、完全制御されたビルド」が完成する。
—
3. チーム開発でこの「IRハック」をスケールさせるための設定とルール
手動でコマンドを叩くだけでは、属人化を招くだけだ。チーム開発においてLLVMパイプラインのカスタマイズを安全に共有・運用するためのベストプラクティスを提示する。
A. 開発環境の統一：絶対入れるべき神プラグインとツール
VS Codeをエディタとして採用しているチーム向けに、LLVM IRの構造を視覚的に追うための必須拡張機能と設定を示す。
VS Code 拡張機能
1. LLVM IR Syntax Highlighting (作者: LLVM)
- `.ll` ファイルの構文ハイライトに必須。レジスタ（`%1`, `%val`）や基本ブロック（`label:`）を色分けする。
2. Graphviz Viewer (作者: Jarek Lukski)
- 後述するCFG（制御フローグラフ）の可視化ファイルをプレビューするのに使う。
`.vscode/settings.json` の設定例
{
“files.associations”: {
“.ll”: “llvm”,
“.bc”: “binary”
},
“editor.rulers”: [80, 120],
// LLVMツール群のパスをプロジェクトローカルに固定（バージョン差異による挙動崩れを防ぐ）
“llvm.executablePath”: “/usr/lib/llvm-16/bin/”
}
B. ビルド自動化のための設定ファイル（CMakeカスタムターゲット）
大規模なプロジェクトにおいて、特定の高パフォーマンスモジュールだけ「Clangフロントエンド通過後にカスタムIR最適化を挟む」ためのCMakeスニペットを提示する。
`CMakeLists.txt` のベストプラクティス
cmake_minimum_required(VERSION 3.20)
project(LLVMHackDemo C)
set(CMAKE_C_STANDARD 11)
ターゲットとなるソースファイル
set(TARGET_SRC “target.c”)
set(TARGET_BC “target.bc”)
set(TARGET_OPT_BC “target_opt.bc”)
set(TARGET_OBJ “target.o”)
find_program(CLANG_EXECUTABLE clang REQUIRED)
find_program(OPT_EXECUTABLE opt REQUIRED)
find_program(LLC_EXECUTABLE llc REQUIRED)
1. CソースからLLVM Bitcodeを生成するカスタムコマンド
add_custom_command(
OUTPUT ${TARGET_BC}
DEPENDS ${TARGET_SRC}
COMMAND ${CLANG_EXECUTABLE} -O0 -emit-llvm -c ${CMAKE_CURRENT_SOURCE_DIR}/${TARGET_SRC} -o ${TARGET_BC}
COMMENT “[LLVM] Emitting Bitcode from C source”
)
2. optコマンドでカスタム最適化パイプラインを適用
ここでは GVN -> 冗長コード除去 -> ループアンロール を明示的にパイプ
add_custom_command(
OUTPUT ${TARGET_OPT_BC}
DEPENDS ${TARGET_BC}
COMMAND ${OPT_EXECUTABLE} -passes=’gvn,dead-code-elimination,loop-unroll’ ${TARGET_BC} -o ${TARGET_OPT_BC}
COMMENT “[LLVM] Applying custom optimization passes via opt”
)
3. 最適化済みBitcodeからオブジェクトファイルを生成
add_custom_command(
OUTPUT ${TARGET_OBJ}
DEPENDS ${TARGET_OPT_BC}
COMMAND ${LLC_EXECUTABLE} -filetype=obj ${TARGET_OPT_BC} -o ${TARGET_OBJ}
COMMENT “[LLVM] Compiling optimized Bitcode to object file”
)
4. 最終的なターゲットライブラリ/実行ファイルに紐づけ
add_library(optimized_core STATIC ${TARGET_OBJ})
set_target_properties(optimized_core PROPERTIES LINKER_LANGUAGE C)
この設定により、`cmake –build .` を実行するだけで、開発者は意識することなく「人間がチューニングしたLLVMパイプラインを通ったバイナリ」をビルドし続けることができる。
—
4. プロの眼：最適化パスの暴走を防ぐための「制御フローグラフ（CFG）」解析
LLVM IRを直接いじる際に最も恐ろしいのは、「最適化パスを盛り込みすぎて、未定義動作や無限ループ、あるいはレジスタあふれ（Spill）を引き起こすこと」だ。これを防ぐために、コンパイラが内部でどのようにコードを見ているかを視覚化するデバッグ手法を常駐させよ。
以下のコマンドで、各関数の制御フローグラフ（CFG）をDot言語形式で出力できる。
関数ごとのCFGをDotファイルとして出力
opt -passes=’dot-cfg’ target_opt.bc -disable-output
生成された `.dot` ファイル（例: `cfg.process_data.dot`）を、Graphviz等を使ってSVGに変換する。
dot -Tsvg cfg.process_data.dot -o cfg.svg
このグラフを開くと、基本ブロック（Basic Block）同士の分岐やループ構造が視覚化される。「想定していない分岐パスが生まれていないか」「不要な投機的実行（Speculative Execution）が挿入されていないか」を、テックリードとしてコードレビューの要所に組み込むべきだ。
—
最後に：低レイヤを支配する者だけが到達できる領域へ
C言語という言語の美しさは、「ハードウェアに近いこと」だ。しかし、現代の複雑化したスーパースカラプロセッサと、保守的なコンパイラ最適化の間に横たわる溝は深い。
今回紹介したLLVM Bitcodeの直接操作と `opt` パイプラインのハックは、その溝を自らの手で埋めるための究極の手段である。「コンパイラがやってくれるだろう」という受動的な姿勢を捨て、IRレベルでプログラムの生命線を支配したとき、あなたの書くCコードは、競合が真似できない圧倒的な実行速度という果実を実らせるはずだ。
妥協なきコードベースを、チーム全体で築き上げていこう。