(I have very limited experience in the LLVM environment, so please, take this proposal with open minds.)
Rationale-
Much like it happens in the case of HLSL, GLSL is a graphics (and GPGPU) language in increasing demand. Including a subset of GLSL into the Clang family should be easier now with HLSL already built-in. GLSL is backed by a solid specification, making for easier step-by-step integration. Even if this project would sound redundant having Khronos’ glslangValidator, there is a great deal to be gained by bridging the gap between GLSL and LLVM IR directly. Clang tooling already give it a rich environment for code improvement and analysis, extending these functionalities to GPU-related software could prove invaluable. This new compilation pipeline should be devised as an offline shader compiler, improving highly demanding computational offloading to GPU, by providing a great deal of precision. Adding GLSL’s graphics-specific features, from this starting ground, would benefit from the tooling environment already created around it.
Expected output-
LLVM IR generation capabilities from GLSL source (particularly for compute pipelines at least).
Clang tools expansion to cover implicitly parallel languages like GLSL and HLSL (and SPIR-V).
Required effort-
This is the part I struggle with the most. I have been scouting the code-base looking for the specific changes required by both expected outputs but it would be interesting to discuss first. Having a look at the article on HLSL support I believe, similar changes would apply in the context of the first point.
As for the second one, I guess it would depend on the number and complexity of the tools adapted. However, I am curious as to how agnostic static-analysis tools are already? I was under the impression that these operated on LLVM IR and Clang AST, meaning there should be little problem with portability. Now I am starting to realize the problem will have to do with language-specific intrinsics not being properly digested by the tools. If that is the case, it should be interesting to work it out regardless of the GPU source-level language included on Clang anyway.
I’m one of the engineers at Microsoft behind the work to bring HLSL into Clang. One big point I want to clarify here is that HLSL isn’t really built into clang yet. We’re working on it, but there’s still a lot of work to do, and that work spreads up and down the compiler.
For HLSL, we still have a lot of work to do to add support in Clang for the language constructs as well as through the LLVM layer to generate code for DirectX and Vulkan.
Personally, I think it would be awesome to add GLSL support to Clang, and while there are some similarities between HLSL and GLSL (and OpenCL), which would allow for sharing code, there’s also a whole lot that makes GLSL unique. I say this just as a caution to not underestimate the scale of the effort.
Thank you for starting the discussion on this! I don’t have firm opinions on the technology one way or the other, but I would echo what @beanz says about the amount of effort involved. In addition to GLSL needing its own implementation work, I am concerned about the proliferation of GPU programming technology in Clang – we’re still in the process of adding HLSL and SYCL support to Clang, on top of our existing OpenMP, CUDA, and OpenCL offerings (all of which are also under active development). At some point, I think we will need to invest in trying to unify what we can from these implementations and some of those requests may come with more urgency for whoever goes to add the next GPGPU language to Clang.
I would love to seize the opportunity to throw a few ideas at you, in case there is something worth building. I will focus on HLSL for this reply, half of what I suggested in my original post already affects it anyway.
One big point I want to clarify here is that HLSL isn’t really built into clang yet. We’re working on it, but there’s still a lot of work to do, and that work spreads up and down the compiler.
Reading through the docs on HLSL support for Clang, there is this recurrent message: HLSL support in Clang is currently focused on compute shaders. Initially, I thought, the same could be true for GLSL. I guess my question becomes,
Is Clang already fully supporting compute shaders for HLSL?
On top of this, have you promoted any efforts to bring static analysis tools from Clang to be used by the HLSL frontend? I would expect it to be a huge deal to have clang tools work on top of HLSL. Particularly, things like syntax checking, AST consumers or even code coverage could be fairly interesting new projects to be discussed.
Is there any hard restriction on building those tools?
If abstracting GPU languages at Clang AST level were possible, then devising ways to create support tooling would make a lot of sense IMO.
No. The language support is still pretty limited. We’ve added enough language support that we can get some extremely simple and carefully crafted HLSL to parse, at the moment we’re focused on getting correct code generation so that we can get those simple shaders executing in the DirectX runtime.
Since Clang’s language support for HLSL is still not complete we haven’t been looking at bringing static analysis or any of the more complex tools. We’ve done some initial work to get clangd working as a language server for HLSL. In terms of supporting syntax checking, and ASTConsumers support, that all comes with the turf of adding support to Clang. Each feature we’ve added to clang is represented in the AST and can be traversed, and manipulated through all the normal APIs. We’ve not added any HLSL-specific tooling beyond that yet.
Adding code coverage support for HLSL is much more complicated than just a source level tooling so I wouldn’t group that in with the other kinds of things you’ve listed.
I’m not sure in what sense you’re asking this. We have no policy restrictions, but there are technical restrictions. HLSL support is not complete in Clang, so adding advanced language-focused tooling will be quite difficult.
Overall I’m not really sure what you’re looking for here. Do you have a tool in mind that you wan to build?
The current production HLSL compiler is a fork of Clang, so it is possible to represent HLSL in a Clang-ish AST today. We do use that in the HLSL compiler for rewriters and other source tooling, but it is very HLSL-centric. The HLSL compiler also supports SPIR-V generation directly from Clang ASTs (rather than lowering through LLVM).