同じソースコードでもコンパイラ変更で速くなる理由｜GCC・LLVMの最適化とC言語「未定義動作」の罠

同じコードでもコンパイラで速度が激変する理由

プログラミング言語の入門書では、よく「コンパイラとは、人間が書いたソースコードを CPU が読める機械語（0 と 1 の命令）へ翻訳するソフトです」と説明されます。しかし「翻訳」という言葉のイメージだけで捉えていると、コンパイラを変えただけで処理速度が 2 倍になったり、逆に長年動いていた処理が壊れたりする現象が不思議に見えてしまいます。

実際には、現代のコンパイラは書いた通りの手順を上から順番に機械語へ置き換えているわけではありません。「最終的に外から見た計算結果（観測可能な振る舞い）さえ同じになるなら、途中の手順は CPU が最も速く走れる形へ徹底的に組み替えてよい」というルールのもとで動いています。

英語の翻訳家に例えると、単語を 1 個ずつ辞書通りに置き換えるんじゃなく、「要するにこういう意味じゃろ！」って文章全体を最初から一番伝わりやすい構成に書き直してくれるベテラン編集者みたいなもんじゃな。

まさにその通りです！同じ設計図を渡しても、担当する棟梁（コンパイラ）の知識や最新工具（CPU命令）の使いこなし方で、完成する建物の無駄のなさが大きく変わるんですね。

直訳ではなく再設計を行う三層構造の仕組み

なぜコンパイラごとにこれほど解釈力や速度の差が生まれるのでしょうか。現代の代表的なコンパイラ（GCC や Clang / LLVM、そして LLVM を採用している Rust の rustc など）は、内部が大きく 3 つの階層（フロントエンド・ミドルエンド・バックエンド） に分かれて連携しています。

たとえば Rust（rustc）の場合、自分が書いたコードを 1 行も変えていなくても、コンパイラのバージョンを上げるだけで背後の LLVM（ミドルエンドおよびバックエンド） が新しい世代へ更新され、全体の処理速度が数%〜10%以上自然に向上することがよくあります。

かつてのP-CodeとC言語出力ビルドの記憶

少し昔の開発現場をご存じの方なら、この「バックエンドの最適化エンジンを借りる威力」に心当たりがあるかもしれません。かつて業務系システム開発で一世を風靡した PowerBuilder や Delphi、Visual Basic、COBOL、C / C++ など、現場では時代ごとに多様なツールや実行ファイル（.exe や .dll）が使われてきました。

たとえば PowerBuilder は、普段の開発時はスクリプトを P-Code（疑似コード・中間コード） に変換し、実行時に PBVM などのランタイム DLL（仮想マシン）が解釈して動かすという、現代の Python（.pyc バイトコード＋仮想マシン実行）にとてもよく似た仕組みを採っていました。

しかし、当時の CPU 性能でループ処理や数値計算の速度を極限まで稼ぎたい場面向けに、「マシンコード生成」というビルドオプションが用意されていました。これを選んで実行ファイルや DLL を作ると、裏側では驚くような力技が走っていたのです。

1. PowerBuilder が画面定義やスクリプトを解析し、一時フォルダへ大量の C 言語ソースコード として猛烈な勢いで自動出力（トランスパイル）します。

2. バックグラウンドで外部の本物の C コンパイラ（Watcom C/C++ など）を呼び出します。

3. 実績のある C コンパイラの強力なオプティマイザ（最適化エンジン）に機械語への変換とリンクを丸投げし、高速なネイティブバイナリを生成します。

自前でゼロから CPU ごとの最適化エンジンを作るのは途方もない労力がかかるため、「人間はポインタのない安全な言語で業務ロジックを書き、最後の機械語最適化だけは専門のコンパイラに任せる」という合理的な分業が当時から行われていました。この思想こそが、現代の LLVM という共通基盤へそのまま受け継がれています。

コンパイラ更新だけで数倍速くなる四つの最適化

では、コンパイラを変更したり最新バージョンへ更新したりすると、実際にどれくらいの変化が起きるのでしょうか。まずは現場でよく見られる代表的な変更パターンを比較表で整理します。

こうした速度差を生み出している「コンパイラ内部の 4 大最適化テクニック」を具体的に見ていきましょう。

定数畳み込みと分岐ペナルティを消す変形

1 つ目は 「実行する前に計算できる無駄を徹底的に消す」 処理です。たとえば int sec = 60 * 60 * 24; と書いてあれば、コンパイラは最初から 86400 という定数に置き換えます（定数畳み込み）。さらに小さな関数呼び出しは呼び出し元へ直接埋め込んで往復コストを消し（インライン展開）、絶対に到達しない条件分岐は機械語から丸ごと削ぎ落とします（デッドコード除去）。

2 つ目は 「CPU のパイプラインを止めない命令変形」 です。現代の CPU は命令を先読みして流す深いパイプライン構造を持っているため、if 文の予測が外れる（分岐予測ミス）と、先読みしていた処理をすべて破棄してやり直す大きなペナルティが発生します。優秀なコンパイラは、短い if-else をジャンプ命令ではなく CPU の 条件付き移動命令（x86_64 の cmov や ARM64 の csel） に置き換え、一度も立ち止まらずに駆け抜ける機械語へ組み替えます。

自動ベクトル化とファイルを跨ぐLTOやPGO

3 つ目の決定打が、昔のコードを最新コンパイラで再ビルドしたときに最も劇的な差を生む SIMD（Single Instruction, Multiple Data）への自動ベクトル化 です。

20 年前に書かれた素朴な配列の足し算ループであっても、最新の GCC や Clang に通すと「あ、これは 1 個ずつ足す必要はないな」と自動で判断してくれます。そして現代の CPU が備える AVX2（256bit 幅）や AVX-512、Apple Silicon の NEON といった並列演算レジスタを使い、1 回の命令で 4 個〜16 個の数値データをまとめて一撃で計算する機械語 へ自動変換してくれるのです。

4 つ目が、1 つのソースファイルの枠を超えた全体最適化です。

手書きのシフト演算やCPU指定フラグの注意点

ここで面白い逆転現象があります。昔の C 言語の現場では、非力なハードウェアと素朴なコンパイラを補うために、プログラマが「掛け算 x * 8 は遅いからビットシフト x << 3 で書こう」「配列の添字ではなくポインタ演算を複雑に回そう」「register 修飾子を付けまくろう」といった 手動の高速化ハック を競う文化がありました。

ところが現代のコンパイラにとっては、人間が良かれと思って書いたトリッキーなシフト演算や複雑なポインタ操作こそが「ループ全体の意図（データの依存関係）」を読み解く邪魔になり、せっかくの SIMD 自動ベクトル化を阻害する足枷になってしまう ことが多々あります。今は小細工をせず、x * 8 や素直な配列ループで意図を明確に書いたほうが、コンパイラが迷わず最速の並列命令を吐き出してくれます。

うわぁ……昔の C 言語といえばポインタのパズルと (data >> 4) & 0x0F みたいなシフト演算の暗号ばっかりで、あれが嫌になって C から離れたんじゃけど、今は素直に書いたほうが速くなるんか！

そうなんです！ただ、最適化フラグを使うときには実務上 2 つだけ注意点があります。手元の PC 専用ツールなら -march=native を付けると搭載 CPU の最新命令を 100% 使い切れますが、他の PC や古いサーバーへ配布する実行ファイルに -march=native を付けると、非対応の CPU で動かした瞬間に Illegal instruction（不正命令エラー）で即座にクラッシュ してしまいます。また -Ofast（-ffast-math）は IEEE 754 浮動小数点規格の丸め順序や NaN 判定を無視して変形するため、金額計算や厳密な科学計算では絶対に使わないでくださいね。

古いC言語コードを壊す「未定義動作」の罠

ここからが、古い C / C++ のソースコードを最新コンパイラでビルドし直す際に 絶対に知っておかなければならない最大の落とし穴 です。

現場ではよく「10 年前の GCC でビルドした実行ファイルや DLL は今まで一度も落ちずに動いていたし、デバッグ用の最適化なし（-O0）でも正常に動くのに、最新コンパイラで最適化（-O2 や -O3）をかけた瞬間に結果がおかしくなったり脆弱性が生まれたりした！」という怪奇現象が起きます。多くの人が「新しいコンパイラのバグだ！」と疑いますが、99% のケースで犯人はコンパイラではなく、元のコードに潜んでいた 「未定義動作（Undefined Behavior：UB）」 です。

問題は、現代のコンパイラの最適化エンジンが、この規格を 「プログラマは正しい C 言語を書く以上、未定義動作（UB）が起きるような入力は『地球上に絶対に存在しない』と仮定してコードを削ってよい」 という強力な推論ルールとして使っている点にあります。実際に安全チェックが消滅する 2 つの実例を見てみましょう。

符号付き整数オーバーフロー検査が消える罠

C 言語規格では、符号なし整数（unsigned int）が上限を超えた場合は「0 に戻る（ラップアラウンド）」と明確に定義されていますが、符号付き整数（signed int）のオーバーフローは「未定義動作（UB）」 と定められています。

これを知らずに、外部から受け取った正の整数 x に 100 を足したとき、上限を超えてマイナスへ巻き戻っていないか確認しようとして次の安全チェックを書いたとします。

// 危険な例：符号付き整数（int）のオーバーフロー検査
int check_overflow(int x) {
    if (x + 100 < x) {
        // 上限を超えてマイナスに溢れたらエラーにするつもり！
        return -1;
    }
    return x + 100;
}

昔の素朴なコンパイラや -O0 なら、CPU 上で普通に足し算を行い、2 の補数表現でマイナスに溢れれば if の中に入ってエラーを返してくれました。ところが最新の GCC や Clang に -O2 を付けて渡すと、ミドルエンドの最適化エンジンは次のように冷徹な三段論法を組み立てます。

1. 変数 x は符号付きの int 型として宣言されています。

2. C 言語規格上、符号付き int の足し算でオーバーフローは「未定義動作」にあたるため 絶対に起きません。

3. オーバーフローが起きない通常の算数において、x + 100 < x が真（true）になる数は存在しません。したがって、この if ブロックは 一生通らない不要コードなので丸ごと削除します。

結果として、生成された機械語からはエラーチェックの分岐が跡形もなく消え去り、巨大な数値を入れられた瞬間にチェックを素通りしてバッファ破壊などの重大なセキュリティ事故を引き起こします。

ポインタ参照後のNULL検査が消滅する罠

もう 1 つ、大規模な C 言語プロジェクト（過去の Linux カーネルの脆弱性事例などでも有名）で実際に何度も踏まれてきた地雷が、「うっかり先にポインタの中身を読んでしまってから NULL チェックを書く」 パターンです。

// 危険な例：宣言と同時に間接参照してから NULL を調べている
int process_data(struct Packet *ptr) {
    int type = ptr->type;   // ① ここで先に ptr が指すメモリを読んでしまった！

    if (ptr == NULL) {      // ② 直後に「念のため NULL チェック」を書いたが…
        return -1;
    }
    return handle_packet(ptr, type);
}

コードを書いた本人は「最初に変数をまとめて宣言してから ptr == NULL を弾いたから安全だ」と思い込んでいます。しかし最適化コンパイラは ① の ptr->type を見た瞬間に、「① でポインタ ptr を間接参照している以上、もし ptr が NULL なら ① の時点で未定義動作（UB）になっているはず。未定義動作が起きない前提なら、② に到達した時点で ptr が NULL の可能性は 0% になる」 と判定してしまいます。

その結果、② の if (ptr == NULL) return -1; は「無駄な比較」として機械語から完全に削除されます。特殊なメモリ空間や後続処理の条件によってはクラッシュすら起きないまま不正メモリの読み書きへ突き進んでしまうため、目視レビューだけではなかなか見抜けない非常に厄介な罠です。

現場で使えるC言語の防御策とRustの設計美

それでは、手元にある既存の C / C++ コードを最新コンパイラで安全に高速化したい場合と、これから新しく高速なツールを作る場合で、それぞれどう対処すればよいのでしょうか。

保守現場で必須のコンパイルフラグとUBSan

レガシーな C / C++ 資産を最新コンパイラへ移行・保守する現場では、いきなり -O3 だけを付けて本番投入するのは禁物です。以下の 防衛オプションと動的検査ツール（サニタイザー） を組み合わせるのが鉄則になります。

安全と爆速最適化を両立したRustとAI開発

そして「そもそも人間がこんなに神経をすり減らさなくても、安全と最高速を両立できないのか？」という長年の悲願に対する現代の解答が、米国 CISA / NSA / FBI の合同ガイダンスでも移行が強く推奨されているメモリ安全言語 Rust です。

実は C 言語のコンパイラは、2 つのポインタ引数を受け取ったとき「もしかすると同じメモリアドレスを指しているかもしれない（エイリアス問題）」と警戒するため、人間が手動で restrict 修飾子を付けない限り、メモリからの再読み込みを省略できない弱点がありました。

それに対して Rust は、「書き換え可能な参照（&mut T）が存在する間は、他の誰もそのメモリを読み書きしていない」というルールをコンパイラ自身が 100% 保証しています。だから背後の LLVM に対して堂々と 「ここは絶対に重なっていないから全力でレジスタに載せて並列化してよし！（noalias）」 と指示を出せるのです。なお Rust でも整数のオーバーフローはデバッグビルドで即座にパニック検知され、リリースビルド（-O）では C 言語のような「分岐が勝手に消える未定義動作」ではなく 2 の補数によるラップアラウンドとして確定定義 されています（上限チェックが必要な箇所では checked_add などの専用メソッドで明示的に安全処理できます）。

人間がピリピリしながら手作業でメモリ番地を数えなくても、コンパイラさんが「安全確認ヨシ！全力ダッシュヨシ！」って両方やっちゃうんでちね！

しかも今の時代は、Antigravity みたいな AI 開発環境（Gemini）を隣に座らせて、こっちは COBOL や PowerBuilder 時代みたいに「入出力の仕様決め」と「境界値テスト」に集中して、実際の Swift や Python や Rust のコード記述は AI という優秀な常駐プログラマに任せられるけぇ、ほんまに良い時代になったわい。

まさにここが現代の開発における最大の転換点です。多くの企業が AI 導入で失敗するのは、人間側が「何を入力し、例外やゼロ・境界値をどう扱い、どうテストするか」というシステムエンジニア（SE）の仕様設計と検収を放棄して丸投げするからです。人間が仕様とテストの手綱をしっかり握り、実装と最新コンパイラの最適化を AI とモダン言語（Rust / Python / Swift など）に任せる体制を作れば、昔のポインタ地獄で消耗することなく、自分専用の高速ツールを自由自在に生み出せます。

まとめ：コンパイラの力を安全に引き出そう

今回の検証と技術解剖のポイントをまとめます。

• コンパイラ変更だけで速くなる理由 : 現代のコンパイラは直訳機ではなく、中間表現（LLVM IR / GIMPLE）での等価変形と SIMD 自動ベクトル化・LTO・PGO によって、CPU の限界性能を引き出す再設計エンジンだからです。

• 古い C / C++ コード最大の地雷 : 昔のコンパイラで偶然動いていた「未定義動作（符号付き整数オーバーフローや参照後の NULL チェック）」は、最新コンパイラの -O2 / -O3 では 「絶対に起きない前提」として安全検査ごと消去される ため、必ず -Wall -Wextra や UBSan / ASan（-fsanitize=undefined,address）を通してから更新しましょう。

• これからの最適解 : 新規の高速処理にはコンパイル時に未定義動作を封じ込めつつ LLVM noalias 最適化を引き出せる Rust を選び、人間は仕様策定と境界値テストに専念して AI エージェントを使いこなすのが最も賢い選択です。

お手元に保守中の C / C++ プロジェクトや、これから高速化したい Rust / 各種コードがある方は、軽量モデルではなく 『Gemini 4 Argon』などの最上位推論モデル を選び、以下のプロンプトをコピー＆ペーストして事前の安全監査とコンパイル設定診断を行ってみてください。

以下の記事URLに記載されている「コンパイラ最適化の仕組み（SIMD自動ベクトル化・LTO・PGO）」「C/C++における未定義動作（UB）で安全検査が消滅する罠」「配布環境での -march=native や -ffast-math の注意点」「防衛コンパイルフラグとサニタイザー手順」をすべて精読してください。

https://lab.chihouzakki.com/blog/review/compiler-change-speedup-llvm-gcc-undefined-behavior/

【あなたへの依頼（コード書き換え前の事前監査）】
いきなりソースコードや Makefile / CMakeLists.txt / Cargo.toml を直接書き換えず、まず私のプロジェクトのビルド設定と主要ソースコードを調査し、以下の3点を日本語で分かりやすく報告してください。

1. 【未定義動作・移植性リスクの洗い出し】：最新コンパイラの -O2 / -O3 で最適化かけた際に処理消滅やクラッシュを招くリスク（符号付き整数オーバーフロー、ポインタ参照順、型キャストによる strict aliasing 違反、未初期化変数等）がないか。
2. 【コンパイルフラグとテスト体制の診断】：実行環境（手元専用か他環境配布か）に照らして適切な最適化オプション（LTO等）と、テスト時に導入すべき警告・サニタイザー設定（-Wall -Wextra / UBSan / ASan 等）の提案。
3. 【安全な段階的改善プラン】：私が内容に合意した後、どの順番でテストと設定変更を進めるべきかの実行計画。

コンパイラの「賢すぎる裏側の仕組み」を味方につけて、安全で気持ちよく飛ぶように動くソフトウェア環境を手に入れましょう！

▲ 面倒なポインタ管理も最適化もコンパイラとAIに任せて、人間も猫様もぐっすり安心