なぜそのコードは -O3 をつけても速くならないのか？ GCC Optimization Miss レポートを骨の髄まで使い倒す極限チューニング
幾度となくプロファイリングを重ね、クリティカルパスを特定し、C言語で極限まで無駄を削ぎ落としたはずのループを書いた。そしてコンパイラに `-O3 -march=native -flto` を食らわせる。しかし、期待したスループットは出ず、perfのレポートには相変わらずスカラー演算の無残な残骸が並ぶ。
「なぜコンパイラはこのループをベクトル化しなかったのか？」
頭に浮かぶのは、マニュアルを斜め読みしただけの薄っぺらな知識と、根拠なき `#pragma GCC ivdep` や不可解なポインタの `restrict` 修飾の乱れ打ちだ。これではエンジニアではなく、ただの祈祷師である。
最高峰のパフォーマンスを追求するシステムアーキテクトにとって必要なのは、コンパイラの気分を推測することではない。GCCの内部で何が起き、どの依存関係グラフが最適化の壁となったのかを客観的なログとして引き剥がす技術だ。
本稿では、GCCの隠し札である `-fopt-info` ファミリーを完全に手なずけ、CI/CDパイプラインとコンテナ環境を統合して「最適化の取りこぼし（Optimization Miss）」を完全に根絶する実践的アーキテクチャを解説する。
—
1. コンパイラ内部の迷宮：なぜ `-O3` は敗北するのか？
現代のGCC（特にバージョン11以降）のオプティマイザは非常に高度だ。しかし、彼らは「安全第一」の原則で動いている。少しでもメモリのエイリアシング（別名参照）の懸念や、ループの歩幅（Stride）に不確定要素があれば、容赦なくベクトル化（Autovectorization）やループアンローリングを放棄し、安全なスカラーコードへフォールバックする。
コンパイラが何を考え、どこで諦めたのか。それを知るためのインターフェースが `-fopt-info` である。
核心を突くGCCオプティマイザフラグ群
単に `-fopt-info` と指定するだけでは、情報が洪水のように溢れ返るか、あるいは表層的なメッセージしか得られない。実務で使うべきは、パス名と詳細度を制御した以下の組み合わせだ。
gcc -O3 -march=native \
-fopt-info-vec-optimized \
-fopt-info-vec-missed \
-fopt-info-loop-optimized \
-fopt-info-loop-missed \
-ftree-vectorizer-verbose=2 \
source.c
- `-fopt-info-vec-missed`: SIMD化（AVX2/AVX-512等）の試みがなぜ失敗したかの理由を、ソースコードの行番号付きで暴き出す。
- `-fopt-info-loop-missed`: ループ変換（不変式の外出し、アンローリング、ストリップマイン等）がなぜ阻害されたかを出力する。
- `-ftree-vectorizer-verbose=2`: ベクトル化パスの詳細な内部解析データを標準エラー出力に吐き出す。
—
2. 実践：Optimization Miss レポートの解読とコードの外科手術
実際に、よくある「最適化が阻害されたコード」を例に、GCCが何を語るのかを見ていこう。
阻害されているアンチパターンコード (`matrix_mul.c`)
include
void compute_heavy(float restrict dest, const float restrict src, size_t n, size_t stride) {
for (size_t i = 0; i < n; ++i) {
dest[i] = src[i stride] + 1.0f;
}
}
一見、`restrict` キーワードも付いており、ポインタのエイリアス問題はクリアしているように見える。しかし、これをコンパイルしてみる。
gcc -O3 -march=native -fopt-info-vec-missed matrix_mul.c -c
コンパイラからの「告発状」（出力ログ）
matrix_mul.c:5:5: missed: couldn’t vectorize loop
matrix_mul.c:5:5: missed: not vectorized: complicated access pattern.
matrix_mul.c:6:21: missed: statement supports no vectorization
ここだ。`complicated access pattern`（複雑なアクセスパターン）。
原因は `src[i stride]` にある。`stride` がコンパイル時定数ではないため、硬件のSIMDレジスタに対して連続したメモリ領域（Contiguous memory）としてロードできず、ギャザー（Gather）命令が必要になるか、あるいはメモリアライメントが保証できないとコンパイラが判断したのだ。
アーキテクチャ視点での処方箋
この最適化ミスを解消するためには、メモリアクセスをリニア（連続的）にするか、ストライドが固定であることをコンパイラにコンパイル時定数として教え込む必要がある。もし `stride` が実行時に関数ごとに異なるなら、ループのアンロールや、ブロック分割（Tiling）によるキャッシュ効率の最適化を明示的に設計し直さなければならない。
—
3. Docker環境による完全自動構成：環境依存の排除
開発者のローカルマシン（macOS, Ubuntu, WSL2など）によってGCCのバージョンやデフォルトのターゲットアーキテクチャ（`-march`）が異なると、Optimization Miss の結果も変わり、再現性が担保できない。
厳密なパフォーマンス監査を行うためには、Dockerコンテナ内でターゲットCPUアーキテクチャを完全にエミュレート、または固定してビルドするパイプラインを構築する必要がある。
以下に、GCCの最新版と詳細なレポート出力を自動化する `Dockerfile` を提示する。
高精度解析用 Dockerfile
ベースイメージとして最新の安定版Debianを使用
FROM debian:bookworm-slim
依存パッケージのインストール（最新GCC、make、分析用スクリプト言語）
RUN apt-get update && apt-get install -y \
build-essential \
gcc-13 \
g++-13 \
python3 \
jq \
git \
&& rm -rf /var/lib/apt/lists/
デフォルトのgccをgcc-13にシンボリックリンク設定
RUN update-alternatives –install /usr/bin/gcc gcc /usr/bin/gcc-13 60
作業ディレクトリの設定
WORKDIR /workspace
解析用エントリポイントスクリプトをコンテナ内に配置
COPY scripts/analyze_misses.py /usr/local/bin/analyze_misses.py
RUN chmod +x /usr/local/bin/analyze_misses.py
ENTRYPOINT [“/usr/local/bin/analyze_misses.py”]
—
4. CI/CDパイプライン統合：Optimization Regression の自動検知
「一度最適化されたコードが、機能追加によって再びベクトル化されなくなる（Optimization Regression）」現象は、大規模なC/C++コードベースで頻発する。これを検知するため、CI（GitHub Actions等）のパイプラインに組み込み、「ベクトル化失敗のログが出たらビルドを失敗させる、あるいはメトリクスとして収集する」仕組みを構築する。
Pythonによる自動解析スクリプト (`analyze_misses.py`)
GCCの `-fopt-info` の出力をパースし、構造化データ（JSON）に変換した上で、許容できない最適化ミスを検出するスクリプトの実装だ。
!/usr/bin/env python3
import subprocess
import sys
import json
import re
def run_compilation_and_capture(source_file):
# GCCを呼び出し、最適化情報を標準エラー出力からキャプチャする
cmd = [
“gcc”, “-O3”, “-march=native”,
“-fopt-info-vec-missed”,
“-fopt-info-loop-missed”,
source_file, “-c”, “-o”, “/dev/null”
]
result = subprocess.run(cmd, stderr=subprocess.PIPE, text=True)
return result.stderr
def parse_opt_info(stderr_output):
misses = []
# GCCの最適化ミス出力パターンの正規表現マッチング
# 例: source.c:5:5: missed: couldn’t vectorize loop
pattern = re.compile(r”^(.+?):(\d+):(\d+):\s+(missed):\s+(.+)$”)
for line in stderr_output.splitlines():
match = pattern.match(line.strip())
if match:
filepath, line_no, col_no, level, message = match.groups()
misses.append({
“file”: filepath,
“line”: int(line_no),
“column”: int(col_no),
“level”: level,
“message”: message
})
return misses
def main():
if len(sys.argv) < 2:
print("Usage: analyze_misses.py
sys.exit(1)
source_file = sys.argv[1]
stderr_output = run_compilation_and_capture(source_file)
misses = parse_opt_info(stderr_output)
# 構造化されたレポートを標準出力にJSON形式で吐き出す
report = {
“source”: source_file,
“total_misses”: len(misses),
“misses”: misses
}
print(json.dumps(report, indent=2))
# クリティカルな最適化ミスが存在する場合、CIを強制終了するためのステータスコードを返す
# ここでは例として、ミスが5件以上検出された場合にビルドパイプラインを落とす
if len(misses) > 5:
print(f”[ERROR] Too many optimization misses ({len(misses)}) detected!”, file=sys.stderr)
sys.exit(1)
if __name__ == “__main__”:
main()
GitHub Actions ワークフロー設定 (`.github/workflows/opt_audit.yml`)
name: GCC Optimization Audit
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
audit:
runs-on: ubuntu-latest
container:
image: ghcr.io/your-org/gcc-optimizer-auditor:latest # 先ほど作成したDockerイメージ
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Run Optimization Miss Analysis
run: |
# ターゲットとなるソースファイルを一括スキャンして解析スクリプトに渡す
find src/ -name “.c” | while read -r file; do
echo “Analyzing $file…”
python3 /usr/local/bin/analyze_misses.py “$file” > “opt-report-$(basename $file .c).json”
Wdone
- name: Upload Optimization Reports
uses: actions/upload-artifact@v4
with:
name: optimization-miss-reports
path: opt-report-.json
—
5. エキスパート向け：内部アーキテクチャのハックとメモリ消費の制御
大規模なコードベースにおいて、`-fopt-info` を全ソースに対して詳細に出力させると、コンパイル時間の増大だけでなく、ホストマシンのメモリ消費（RAM）が急騰するという問題に直面する。
1. 内部AST/SSA表現のメモリ爆発を防ぐ
GCCは最適化パス（Tree-SSA, RTL等）ごとに膨大な中間表現（Intermediate Representation）をメモリ上に展開する。`-fopt-info` の詳細度（Verbose）を上げると、ロガーが大量の文字列を生成し、特に並列ビルド（`make -j`）時にメモリ不足（OOM Killer発動）を引き起こす原因となる。
対策: CI環境や大規模ビルドでは、全体に対する `-fopt-info` は抑制し、パフォーマンスクリティカルな特定のサブディレクトリやモジュール（例: 核心的な数値演算ライブラリ層）にのみ選択的にフラグを適用せよ。
2. コンパイラの「忖度」を打ち破るプラグマの極意
どうしてもコンパイラがベクトル化の依存関係を誤認する場合（例：ポインタの指す範囲が実際には重ならないことがプログラマには分かっているが、コンパイル時には証明できない場合）、GCCの拡張構文を用いて明示的に調停する。
// コンパイラに「このループの依存関係は無視してよい（ベクトル化せよ）」と強制命令を与える
pragma GCC ivdep
for (size_t i = 0; i < n; ++i) {
dest[i] = src[i] 2.0f;
}
ただし、このプラグマを多用するのはアーキテクトとしての敗北を意味する。`-fopt-info-vec-missed` が告げる「loop carried dependence」や「not vectorized: data ref analysis failed」の根本原因（型キャストのミスマッチ、構造体のパディングによるアライメント不足など）をコード構造のレベルでリファクタリングすることこそが、真の低レイヤエンジニアリングである。
---
結び：コードとコンパイラの対話を支配せよ
コンパイラは魔法の箱ではない。彼らは冷徹なルールと依存関係グラフに基づいてコードを変換している。
「なぜ最適化されないのか？」と悩む時間は今日で終わりにしよう。`-fopt-info` をパイプラインに組み込み、コンパイラの「言い訳」をJSONとして抽出し、データドリブンにコードの構造的欠陥を撃破する。このサイクルを確立した瞬間から、あなたの書くC言語コードは、ハードウェアの限界性能を容赦なく引き出す最強の武器へと変貌する。