SPIR-V: declare native integer widths in the datalayout

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,008 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à
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
julia
Ambito
compilers

Direzione di ricerca

Inizia dalle varianti di datalayout SPIR-V in src/spirv.jl, alle righe collegate, e confrontale con la modifica del datalayout SPIR-V in LLVM upstream. Aggiungi le larghezze degli interi nativi sia a spirv64 sia a spirv32, poi convalida con i test PoCL di KernelAbstractions e OpenCL.jl, inclusa la configurazione del traduttore Khronos.

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

Descrizione

spirv

GPUCompiler's SPIR-V datalayout doesn't declare native integer widths:

https://github.com/JuliaGPU/GPUCompiler.jl/blob/94f8fbeb3986319e4900c7c9c97799c7bd718f05/src/spirv.jl#L142-L144

Upstream LLVM added n8:16:32:64 to its SPIR-V datalayouts in llvm/llvm-project#110695, because without it "optimisation passes, such as InstCombine, [get] ideas and e.g. [shrink] to non byte-multiple integer types, which is not desirable and can lead to breakage further down in the toolchain".

We hit this with Julia 1.13 (LLVM 20): in KernelAbstractions' PoCL exception path, a switch on a function returning 0, 1 or 2 gets narrowed to i2:

%trunc = trunc nuw i64 %0 to i2
switch i2 %trunc, label %L21 [
  i2 1, label %L18.thread
  i2 0, label %L23
]

LLVM's SPIR-V back end happens to cope, since it rounds integer widths up to 8/16/32/64/128 bits (SPIRVGlobalRegistry::adjustOpTypeIntWidth), but:

  • other consumers may not: the Khronos translator presumably needs SPV_INTEL_arbitrary_precision_integers for such types (not verified);
  • libspirv replaces the module's datalayout with its target machine's, which does include n8:16:32:64, so we optimize under different assumptions than the back end compiles under;
  • odd-width arithmetic has to be masked again once widened.

The fix is to add n8:16:32:64 to both variants (spirv64 and spirv32), as upstream does. It only affects which integer widths the optimizer considers native, not type sizes, alignment or pointers. It should be validated with KernelAbstractions' PoCL tests and OpenCL.jl's PoCL tests, including the Khronos translator configuration.

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.