Not really. LLVM does support compute mode SPIR-V, and _very_ recently graphics-mode SPIR-V which is being dogfooded by the highly WIP HLSL front-end in Clang (I couldn't get a trivial fragment shader to build with it a few weeks ago). Clang does not support compiling graphics-mode SPIR-V from C or C++.
This seems similar to the Vulkan Clang Compiler (which is not in-tree of LLVM), although it has some interesting differences such as implementing shader functions with new specifiers like `__hcc_vertex` rather than repurposing attributes for it like `[[clang::annotate("shady::entry_point::vertex")]]`.
Have a look at QBE as it may provide basic optimizations and some significant performant boost: cproc + QBE and I get 70% of gcc 13.2 -O2 speed in my benchmarks, tinycc is 2 times slower than gcc 13.2 -O2 in the same benchmarks (my benchmarks are very basic, but it shows...).
We are talking gcc complexity is grotesque/absurd for those 30%, not to mention this is now brain damaged c++ (one of the biggest mistakes in open source software ever).
I know QBE is for CPUs, but maybe there is something there for GPUs.
Haven't actually used this project yet, but I occasionally stop by his stream on twitch. Legend.
does this also already exist on llvm toolchain?
Not really. LLVM does support compute mode SPIR-V, and _very_ recently graphics-mode SPIR-V which is being dogfooded by the highly WIP HLSL front-end in Clang (I couldn't get a trivial fragment shader to build with it a few weeks ago). Clang does not support compiling graphics-mode SPIR-V from C or C++.
This seems similar to the Vulkan Clang Compiler (which is not in-tree of LLVM), although it has some interesting differences such as implementing shader functions with new specifiers like `__hcc_vertex` rather than repurposing attributes for it like `[[clang::annotate("shady::entry_point::vertex")]]`.
Have a look at QBE as it may provide basic optimizations and some significant performant boost: cproc + QBE and I get 70% of gcc 13.2 -O2 speed in my benchmarks, tinycc is 2 times slower than gcc 13.2 -O2 in the same benchmarks (my benchmarks are very basic, but it shows...).
We are talking gcc complexity is grotesque/absurd for those 30%, not to mention this is now brain damaged c++ (one of the biggest mistakes in open source software ever).
I know QBE is for CPUs, but maybe there is something there for GPUs.
QBE has no support for SIMD last I looked into it, so I don't think it would be appropriate for an SPMD language. https://todo.sr.ht/~mpu/qbe/5
It's common for shader compilers to invent their own IR, like Shadey and Slang IR.