Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SPIR-V: loop closed forms introduce i65 arithmetic

Aperta
  • Qualcosa non va?
#1,050 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
julia
Ambito
backend-api-design, compilers

Direzione di ricerca

Start by tracing the SPIR-V compilation pipeline and how it handles the loop exit value rewritten by IndVarSimplify. The issue identifies ScalarEvolution's BinomialCoefficient in llvm/lib/Analysis/ScalarEvolution.cpp as the source of i65 arithmetic and lists legalization or pipeline changes as possible approaches. Done means the loop compiles to SPIR-V without unsupported integer widths; the issue does not identify a specific test.

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

Descrizione

A loop that sums a range doesn't compile for SPIR-V:

using oneAPI
function kernel(a, n)
    s = 0
    for j in 1:n
        s += j
    end
    a[1] = s
    return
end
@oneapi kernel(oneArray([0]), 10)
# ERROR: Failed to compile to SPIR-V with the SPIR-V back-end:
# LLVM ERROR: OpTypeInt type with a width other than 8, 16, 32 or 64 bits requires
# the following SPIR-V extension: SPV_ALTERA_arbitrary_precision_integers

This fails with oneAPI.jl main and GPUCompiler 2.16 on Julia 1.10, 1.11 and 1.12, on an Arc A770. The Khronos translator, loaded as a library, crashes the process on the same IR.

The loop is replaced by its closed form, and ScalarEvolution computes that at 65 bits:

%5 = zext nneg i64 %4 to i65
%7 = zext i64 %6 to i65
%8 = mul i65 %5, %7
%9 = lshr i65 %8, 1
%10 = trunc i65 %9 to i64

The width comes from BinomialCoefficient in llvm/lib/Analysis/ScalarEvolution.cpp, which multiplies at W+T bits (here 64+1) so it can divide by 2^T exactly. It doesn't consult the datalayout, so declaring native integer widths (#1027) doesn't help; I checked with that branch. IndVarSimplify then materializes the expression when it rewrites the loop's exit value.

Possible fixes:

  • legalize odd-width integer arithmetic before handing the module to the SPIR-V back-end or translator;
  • keep exit-value rewriting out of the SPIR-V pipeline (there's only the global -replexitval option for that);
  • fix it in LLVM's SPIR-V back-end, which could legalize these widths itself.
Lingua principale
Julia
Stelle
188
Fork
71
Merge medio
1g 12h
PR unite (30g)
72

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.