BukeBeyond wrote: > 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.
You are right! `#pragma OPENCL EXTENSION __cl_clang_kernel_stub : disable` would be the better place for this switch, though it may be more difficult to implement than an experimental Clang flag. It is possible the stub generation here or the global variable optimization may improve in the future, when the stub feature can be safely enabled for all cases. Kernels have exclusive access to private (register) and local (core memory) objects, but we need to give access to these states from other functions and methods without explicit wiring. Imagine a print() function that needs to be wired at every use, and the state passed everywhere would make for very ineloquent code! We lifted some artificial limits in Clang and OpenCL to allow a global pointer to a private object inside the kernel. The optimization passes in LLVM do an excellent job eliminating everything, Methods, Lambdas to a flat stream of code in the kernel body. All the struct definitions are also eliminated, which otherwise Clspv cannot handle. 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
