jhuber6 wrote: > This commit breaks a critical optimization for us. We have a project that > compiles most of the C++26 language features to Vulkan SPIRV.
I've thought about doing that, since I've spent a few years just using normal C++ to write GPU runtimes. The main issue right now is that there's no SPIR-V intrinsics for all the core compute functions like getting a lane mask, ballot, or thread ID. > One optimization we rely on is the elimination of global variables. > Generating a second stub copy of the kernel breaks this optimization. > While we disabled the code generation from this commit, a better and more > general solution may be to introduce a Clang flag like > -fno-opencl-kernel-stub. This may allow other ambitious projects like ours to > pursue modern C++ on Vulkan. We will soon open-source our project, which we > envision will also benefit the AMD community. Doesn't OpenCL have an extension system? You could make an extension to disable this feature instead of putting it in the compiler I'd think. I'm not sure how SPIR-V works, but normally we differentiate between globals needed for the user and internal globals by their visibility. Hidden visibility variables are internalized at link time / not emitted while others can be read by the user while loading the GPU blob, so they must stay. https://github.com/llvm/llvm-project/pull/115821 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
