#76175 simd: CPU feature vet check under GOEXPERIMENT=simd

AIによる要約であり、誤りを含む場合があります。

概要

GOEXPERIMENT=simd の実験的SIMDパッケージにおいて、CPUフィーチャーチェックが漏れていた場合にパニックが発生するリスクを静的解析で検出するためのvetチェックを追加するproposalです。

ステータス変更

active → hold
2026年4月8日の提案レビューミーティング（@aclements, @adonovan, @griesemer, @ianlancetaylor, @neild参加）で、実装担当者である@aclementsへの判断待ちとしてholdに設定されました。ディレクティブコメント方式かどうかの設計議論が収束しきれておらず、実装の方向性を固める時間が必要と判断されたためです。

技術的背景

現状の問題点

#73787 で承認されたGoの実験的SIMDパッケージ（GOEXPERIMENT=simd）では、CPU命令に直接マッピングされた低レベルな操作（x86のAVX、AVX2、AVX-512など）を利用できます。しかしSIMD命令はそのCPUがその機能をサポートしている場合のみ使用でき、サポートしていないCPUで実行するとSIGILL（不正命令シグナル）やpanicが発生します。
Intel AVX-512だけで21種類のフィーチャーフラグが存在するなど、CPUフィーチャーの空間は非常に複雑です。非自明なSIMDコードで全てのフィーチャーチェックを手動で管理することは困難でエラーが起きやすく、CI環境がたまたまそのフィーチャーをサポートしているハードウェアで動作する場合はテストが通ってしまい、本番環境の別ハードウェアで初めてpanicが発生するという問題があります。このリスクは実際に起きており、Goチーム自身のコードでも同様のミス（#76866）が発生しています。

提案された解決策

当初の提案では、ディレクティブコメントと静的フロー解析を組み合わせたvetチェックを追加することが提案されました。

//cpu:requires X86.AVX2
func F() { ... }

このディレクティブは「この関数の呼び出し元は、呼び出し前にAVX2フィーチャーが利用可能であることを確認しなければならない」ことを示します。vetチェックはフロー解析により、フィーチャーチェック関数がtrueを返すパス上でのみSIMD関数が呼ばれているかを確認します。

これによって何ができるようになるか

SIMDを使ったコードの安全性を静的に担保できるようになります。フィーチャーチェック漏れを早期（開発時・CI時）に検出でき、本番環境でのSIGILLやpanicを防げます。

コード例

// Before: フィーチャーチェックなしで呼び出す危険なコード
func processData(data []float32) {
    v := simd.LoadFloat32x8((*[8]float32)(data))
    // AVX2未サポートCPUではここでSIGILLが発生する
    v.Add(v).Store((*[8]float32)(data))
}
// After: フィーチャーチェックを行い、vetが適切さを検証
//cpu:requires X86.AVX2
func processDataSIMD(data []float32) {
    v := simd.LoadFloat32x8((*[8]float32)(data))
    v.Add(v).Store((*[8]float32)(data))
}
func processData(data []float32) {
    if !simd.X86.AVX2() {
        return processDataFallback(data)
    }
    // ここでAVX2の利用可能性が保証されているため、vetはOK
    processDataSIMD(data)
}

議論のハイライト

ディレクティブ vs 推論: 当初はディレクティブコメント方式が提案されたが、@ianlancetaylorと@griesemeが「ディレクティブコメント+vet強制はGoの言語拡張と同等であり、悪い前例になる」と強く反対。その後、ディレクティブなしの型推論ライクな分析（Hindley-Milner型推論に類似したアプローチ）の実装が模索されました。
推論方式の問題点: @aclementsが推論版を実装した結果、エラーメッセージが「コールチェーンのどこかでフィーチャーチェックが必要」という曖昧なものになり、false positiveの可能性もあるため、vetの基準（false positiveゼロ）を満たせないと判断されました。
最終方針: 推論版の解析はvetではなく、IDE（gopls）のデフォルト解析として提供することになりました。オプションのアノテーションを使ってエラーメッセージの精度を改善する方向性も検討されています。
Rob Pikeの懸念: アーキテクチャ固有の低レベルAPIの複雑さがGoの設計哲学（ポータビリティ）に反するという根本的な懸念が示されました。ただしSIMD全体の方向性は別issueで議論されるべきとされています。
実際のバグ事例: GoチームがSIMDパッケージのテスト中に、このvetチェックが防ごうとしているのとまったく同じミス（#76866）を犯していることが判明し、チェックの必要性が実証されました。

Go Proposal Weekly Digest

simd: CPU feature vet check under GOEXPERIMENT=simd

要約

概要