Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

SPIR-V: declare native integer widths in the datalayout

Open Beginner friendly
  • Is something wrong?
#1,008 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
julia
Domain
compilers

Research direction

Start with the SPIR-V datalayout variants in src/spirv.jl at the linked lines and compare them with upstream LLVM's SPIR-V datalayout change. Add the native integer widths to both spirv64 and spirv32, then validate with KernelAbstractions' and OpenCL.jl's PoCL tests, including the Khronos translator configuration.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Julia
Stars
188
Forks
71
Avg merge
1d 17h
Merged PRs (30d)
60

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JuliaGPU/GPUCompiler.jl

All issues in JuliaGPU/GPUCompiler.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.