SPIR-V: emit OpFreezeKHR via SPV_KHR_poison_freeze

Aperta
  • Qualcosa non va?
#1,074 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
julia
Ambito
compilers, devtools

Direzione di ricerca

Start by checking the Yggdrasil recipe for SPIRV-Tools and its current SPIRV_Tools_jll version; the issue says v2026.3 and v2026.4 include headers that recognize PoisonFreezeKHR. Then validate a module containing OpFreezeKHR, and check whether IGC or PoCL supports the extension before deciding how drivers should enable it. Done means the relevant tooling accepts OpFreezeKHR and the driver support or device-gated enablement gap is resolved.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Without an extension, SPIR-V can't represent freeze. Both back-ends replace a freeze with its operand (a null constant for a frozen undef/poison), which is wrong whenever a poison value reaches the instruction at run time. SPV_KHR_poison_freeze adds a real OpFreezeKHR, and both the Khronos translator and the LLVM back-end support it as of version 23. Since #1073 GPUCompiler no longer strips freeze, so passing extensions="+SPV_KHR_poison_freeze" already makes both back-ends emit it.

Two things have to happen before we can rely on it:

  • SPIRV-Tools. SPIRV_Tools_jll 2025.4 doesn't recognize the PoisonFreezeKHR capability (Invalid capability operand: 5156), so the validator, spirv-opt and the disassembler all fail on such modules. The extension landed in SPIRV-Headers in March 2026 (KhronosGroup/SPIRV-Headers#573), and SPIRV-Tools v2026.3 and v2026.4 bundle headers that include it. That needs a Yggdrasil bump, then a check that the validator accepts OpFreezeKHR and not just the capability.
  • Drivers. As far as I can tell from code search, neither IGC (oneAPI.jl, OpenCL.jl on Intel) nor PoCL (OpenCL.jl on CPU) mentions the extension yet, and both back-ends declare it whenever a module contains freeze. Until drivers accept it, it can only be enabled where the device reports it, e.g. from oneAPI.jl or OpenCL.jl based on the device's extension list, not by default in GPUCompiler.

Without the extension, both back-ends turn freeze of a constant undef/poison into a null constant, which is fine because LLVM folds those well before mcgen anyway. The remaining gap is freeze on runtime values, which the back-ends turn into plain copies.

Lingua principale
Julia
Stelle
190
Fork
72
Merge medio
20h 35m
PR unite (30g)
59

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGPU/GPUCompiler.jl

Tutte le issue di JuliaGPU/GPUCompiler.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.