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

CPU backend: invalid SPIR-V ("Block … appears in the binary before its dominator") for nested loops around `@synchronize()`

Open
  • Is something wrong?
#894 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
julia
Domain
compilers

Research direction

The failure comes from SPIR-V validation of code generated for the CPU backend, so start with the kernel-to-LLVM path in src/ and the uniform-variable handling that the docstring of @uniform describes. Reproduce with the snippet in the issue to get the spirv-val error, then inspect the IR from @device_code_llvm around the masked assignments to a and b. Done would mean the kernel validates, which requires either fixing block ordering in the SPIR-V back-end or rejecting the pattern earlier with a clear error.

Written by the indexing model from the issue text.

Description

This kernel does not compile for the CPU backend: the SPIR-V generated for it fails validation.

using KernelAbstractions

@kernel function f!(@Const(v))
    n = size(v, 1)
    a = 0f0
    b = 0f0
    j = 0
    while j < n
        d = 0
        while d < 64
            @synchronize()
            d += 8
            if d < 64
                a = 2f0
            elseif j + 64 < n
                b = b
            end
            @synchronize()
        end
        j += 64
    end
end

v = rand(Float32, 256, 16)
f!(CPU(), 16)(v; ndrange=256)

error: line 209: Block '4[%ok19_loopexit]' appears in the binary before its dominator '7[%ok25]'
  %ok25 = OpLabel

ERROR: Failed to validate generated SPIR-V.
If you think this is a bug, please file an issue and attach /tmp/jl_….bc and /tmp/jl_….spv.

KernelAbstractions 0.10.0, GPUCompiler 2.14.0, SPIRV_LLVM_Backend_jll 23.1.1+7, SPIRV_Tools_jll 2025.4.0, Julia 1.13.1, Linux x86-64.

The kernel does not follow the docstring of @uniform: the counters of its loops are plain locals, assigned in masked regions. With n, j and d declared @uniform it compiles, and with unsafe_indices=true too. But the mistake is reported as this error from spirv-val, and it depends on the shape of the code: the same kernel with a single loop, without the if, or with only one branch compiles.

The LLVM IR from @device_code_llvm looks valid. A padding work-item goes to err, the others to two nested loops:

conversion1:
  br i1 %.not.not.not, label %err, label %ok19
ok25.lr.ph:                                       ; preds = %ok19
  br label %ok25
L81:                                              ; preds = %ok25
  call void @_Z22__spirv_ControlBarrierjjj(i32 2, i32 2, i32 784)
  call void @_Z22__spirv_ControlBarrierjjj(i32 2, i32 2, i32 784)
  br label %ok25
L93:                                              ; preds = %ok19, %err
  ret void
err:                                              ; preds = %conversion1
  call fastcc void @gpu_report_exception({ i32, i64 } %state1, ptr addrspace(1) @exception.7)
  call fastcc void @gpu_signal_exception({ i32, i64 } %state1)
  br label %L93
ok19:                                             ; preds = %ok25, %conversion1
  br i1 %.not819, label %ok25.lr.ph, label %L93
ok25:                                             ; preds = %L81, %ok25.lr.ph
  br i1 %11, label %L81, label %ok19

So there may be two things here: the SPIR-V back-end orders the blocks of this CFG wrongly, and @kernel could reject a loop around @synchronize whose condition reads a variable assigned in a masked region.

Found by removing unsafe_indices=true from a kernel written with it (FluxML/NNlib.jl#791).

Dominant language
Julia
Stars
529
Forks
87
Avg merge
1d 1h
Merged PRs (30d)
66

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/KernelAbstractions.jl

All issues in JuliaGPU/KernelAbstractions.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.