Replace @ka_code_llvm with GPUCompiler's @device_code_* - #784
Merged
Merged
Conversation
`@ka_code_llvm` reflected on the host-side lowering of a kernel and explicitly rejected GPU backends. On 0.10 the CPU backend compiles through OpenCL and `const CPU = POCLBackend <: GPU`, so that guard now rejects every kernel on every backend: the macro cannot be called at all, and nothing in the test suite covered it. Remove it, and forward GPUCompiler's `@device_code_*` macros from KernelAbstractions instead. They install a compilation hook for the duration of the wrapped expression, so they report on the code a backend really generates, and they do that for any GPUCompiler-based backend -- the in-tree CPU backend as well as CUDA, AMDGPU, oneAPI or Metal. They are deliberately not exported: the backend packages export macros of the same name, and `using CUDA, KernelAbstractions` would otherwise make the name ambiguous. `@ka_code_typed` stays as it is. It reflects on the kernel function as the host sees it, which is backend-independent and still works; its docstring now points at the `@device_code_*` macros for looking at generated device code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DbbtGLjxXpt7kZj6h2yVdK
Contributor
Benchmark ResultsShow table
Benchmark PlotsA plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #784 +/- ##
==========================================
+ Coverage 65.04% 65.40% +0.36%
==========================================
Files 23 23
Lines 2017 2012 -5
==========================================
+ Hits 1312 1316 +4
+ Misses 705 696 -9 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
vchuravy
commented
Sep 15, 2026
…blic Review feedback. `@ka_code_typed` reflects on the host-side lowering of a kernel just as `@ka_code_llvm` did, and `@device_code_typed` covers what it was for -- including the Cthulhu `interactive=true` path -- so it goes too. It was the only user of InteractiveUtils and UUIDs in the package, so both drop out of the dependencies. test/reflection.jl only ever exercised `@ka_code_typed`, so it goes as well, along with its `Testsuite` entry. The forwarded `@device_code_*` macros are now marked `public` on 1.11 and later, through `Meta.parse` since `public` is a parse error on 1.10. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DbbtGLjxXpt7kZj6h2yVdK
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@ka_code_llvmis dead code on 0.10-dev.It reflected on the host-side lowering of a kernel and explicitly rejected GPU backends:
Since the CPU backend became an OpenCL backend and
const CPU = POCLBackend <: GPU, that guard fires for every kernel on every backend, so the macro cannot be called at all:Nothing in the test suite covered it, which is why it went unnoticed.
What this does
Removes
@ka_code_llvm/ka_code_llvm, and forwards GPUCompiler's@device_code_*macros fromKernelAbstractionsin its place:These install a compilation hook for the duration of the wrapped expression, so they report on the code a backend actually generates rather than on the host-side lowering, and they do so for any GPUCompiler-based backend — the in-tree CPU backend as well as CUDA, AMDGPU, oneAPI or Metal. That makes them a strictly more capable replacement than the CPU-only macro they replace. The one behavioural difference worth knowing, documented in the docstrings: the wrapped expression is really evaluated, so the kernels it launches are compiled and run.
They are not exported, because the backend packages export macros of the same name and
using CUDA, KernelAbstractionswould otherwise make the name ambiguous; hence the qualified spelling above.@ka_code_typedis untouched — it reflects on the kernel function as the host sees it, which is backend-independent and still works. Its docstring now points at the@device_code_*macros for looking at generated device code.Also: a
Reflectionsection rewrite indocs/src/api.md, a 0.10 changelog entry, and a test intest/runtests.jlasserting thatKernelAbstractions.@device_code_llvmover a kernel launch produces IR for that kernel and runs it.Testing
julia --project=test test/runtests.jl: 2484 pass, 2 errors — both the pre-existingifelse on aggregate typesSPIR-V translation failures (ComplexF32/ComplexF64), which reproduce unchanged onmain.🤖 Generated with Claude Code
https://claude.ai/code/session_01DbbtGLjxXpt7kZj6h2yVdK