Validate emitted Metal AIR declarations against the target AIR version
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
Read the Metal test path and its emitted AIR fixtures, then check how the tests detect whether the offline toolchain is available. Add full AIR verification with metal-opt -air-verify -air-verification-level=full and retain fixtures for each supported AIR version. Done means the final emitted AIR is checked when the tool is available, with execution tests still covering backend selectability.
索引モデルが issue の本文から書いたものです。
説明
I've had an LLM do some investigation, and found that:
Xcode 27's full AIR verifier checks air.* declarations against an AIR-version-specific name and type contract. In a check of 327 concrete AIR declarations emitted from the pinned GPUCompiler.jl/Metal.jl sources, 318 passed and nine failed. Three were Metal.jl quad ballot/vote declarations, four were Metal.jl tensor declarations, and two were older two-operand barrier fixtures being checked as AIR 2.9. Current GPUCompiler.jl legalize_barrier_abi! already fixes the barrier mismatch in its normal path.
The contract changes by AIR version. For example, air.wg.barrier and air.simdgroup.barrier use two i32 operands through AIR 2.8 and three at AIR 2.9; an AIR 2.9 air.atomic.global.load.i32 also has an added i32 operand. Full verification rejects wrong declarations even if they are never called. The lower framework and compiler verification levels did not apply this same declaration check in these probes.
Could GPUCompiler's Metal test path validate final emitted AIR with metal-opt -air-verify -air-verification-level=full when the offline toolchain is available, and retain fixtures for each supported AIR version? That would catch declaration drift before runtime pipeline creation. The full verifier does not prove backend selectability, so this should complement existing execution tests. The regular two-/three-operand barrier rewrite and current MSL-compatible argument type names should stay.
- 主要言語
- Julia
- スター
- 191
- フォーク
- 73
- 平均マージ
- 17時間 5分
- マージ済み PR（30日）
- 43
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
JuliaGPU/GPUCompiler.jl のほかの issue
-
`lower_throw!` treats any function whose name contains `jl_error` etc. as a throw (kernel becomes a trap / segfault)対応中かも @sasmith-14 が 1 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
JuliaGPU/GPUCompiler.jl#1088 ·
メンテナーはふだん 1 日以内に返信
-
spirv
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
JuliaGPU/GPUCompiler.jl#1008 ·
メンテナーはふだん 1 日以内に返信
-
SPIR-V runtime library fails to build on 32-bit hosts: `unbox_int64` returns void対応中かも @maleadt が 18 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
JuliaGPU/GPUCompiler.jl#1085 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
JuliaGPU/GPUCompiler.jl#1074 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
JuliaGPU/GPUCompiler.jl#1060 ·
メンテナーはふだん 1 日以内に返信
JuliaGPU/GPUCompiler.jl の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
MagneticResonanceImaging/MRIReco.jl#366 ·
メンテナーはふだん 3 日以内に返信
-
`AdamW` gives `NaN` for zero-gradient entries of `Float16` parameters (epsilon underflows to 0)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
FluxML/Optimisers.jl#253 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
JuliaGraphs/GraphNeuralNetworks.jl#736 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
`poissonians` is not public, unlike `brownians` and `jumps`対応中かも @isaacsas が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
SciML/ModelingToolkit.jl#5389 ·
メンテナーはふだん 2 日以内に返信