Description: Heterogeneous programming models such as SYCL, OpenMP and OpenACC help developers to offload computationally intensive kernels to GPUs and other accelerators. MLIR is expected to unlock new high-level optimisations and better code generation for the next generation of compilers for heterogeneous programming models. However, the availability of a robust MLIR-emitting C/C++ frontend is a prerequisite for these efforts.
The ClangIR (CIR) project aims to establish a new intermediate representation (IR) for Clang. Built on top of MLIR, it provides a dialect for C/C++ based languages in Clang, and the necessary infrastructure to emit it from the Clang AST, as well as a lowering path to the LLVM-IR dialect. Over the last year, ClangIR has evolved into a mature incubator project, and a recent RFC on upstreaming it into the LLVM monorepo has seen positive comments and community support.
The overall goal of this GSoC project is to identify and implement missing features in ClangIR to make it possible to compile GPU kernels in the OpenCL C language to LLVM-IR for the SPIR-V target. The OpenCL to SPIR-V flow is a great environment for this project because a) it is already supported in Clang and b) OpenCL’s work-item- and work-group-based programming model still captures modern GPU architectures well. The contributor will extend the AST visitors, the dialect and the LLVM-IR lowering, to add support e.g. for multiple address spaces, vector and custom floating point types, and the spir_kernel and spir_func calling conventions.
A good starting point for this work is the Polybench-GPU benchmark suite. It contains self-contained small- to medium sized OpenCL implementations of common algorithms. We expect only the device code (*.cl files) to be compiled via ClangIR. The existing OpenCL support in Clang can be used to create lit tests with reference LLVM-IR output to guide the development. Optionally, the built-in result verification and time measurements in Polybench could also be used to assess the correctness and quality of the generated code.
Expected result: Polybench-GPU’s 2DCONV, GEMM and CORR OpenCL kernels can be compiled with ClangIR to LLVM-IR for SPIR-V.
Skills: Intermediate C++ programming skills and familiarity with basic compiler design concepts are required. Prior experience with LLVM IR, MLIR, Clang or GPU programming is a big plus, but willingness to learn is also a possibility.
I am a second-year undergraduate in Computer Science from Poland, with a background in computer graphics (mainly Vulkan and some OpenGL). I am familiar with C++ and C. Recently, I have developed an interest in SYCL.
I am enthusiastic about this project and eager to contribute. From what I understand, the main tasks involve converting AST to IR, IR to SPIR-V, and extending the IR to support SPIR-V specific features. Implementing such additions would likely facilitate the migration of dxc to newer Clang versions what.
While I lack prior experience with the LLVM codebase, I am keen to learn. Could you recommend any materials that would be helpful in understanding this feature?
I believe your background could be valuable (especially if you’re familiar with shader programming and/or have been in touch with SPIR-V), but note that there is no actual graphics aspect to this project. This is going to be 100% compiler engineering, with the goal of bootstrapping support in ClangIR for the compilation of GPGPU programming models.
@jopperm Hello!
I am very interested in and intrigued by this project, and am fairly familiar with LLVM IR and the llvm-lit and FileCheck tools, and the SPIR-V specification.
I just had a question in mind: I hope I would not need a discrete GPU to be able to compile the GPU kernels? My integrated GPU works fine, and I hope that I could avoid having to install a discrete GPU if it is not strictly required(OpenCL does have runtimes available for Intel integrated GPUs).
In case I sound dumb, please bear with me. I have good experience with Clang and LLVM, but not so much with GPUs!
I understand that the task doesn’t involve graphics directly. My mention of graphics programming was to highlight my familiarity with GPUs and (perhaps too discreetly) the SPIR-V format. Just wanted to ensure you knew where I was coming from!
No, there’s no specific hardware requirement for this project. For the day-to-day work, we’ll use the output of the existing OpenCL support in Clang as a reference for the ClangIR-based flow. When the project progresses to a point where we can actually run kernels, an iGPU (or even the CPU) will be fine to run the device code.
Sounds good, I have some experience in gpu programming.graphics also (vulkan and directx.) I’ve been working with mlir for half a year now. I hope to do some contribution for this project.
I’d certainly be interested in helping out with this project. I have experience with GPU programming and compilers.
I have a question about contributing as a person who currently works in industry. Is there an expectation that GSoC is primarily for undergrads and hobbyists? If so, would I be able to contribute?
AFAIK GSoC is open to anyone, however the expectation is that the contributor can invest ~30h/week (assuming the standard 12-week length), so this cannot be done realistically in addition to a full-time job elsewhere.
I am very interested in this project. Currently, I have built the clangir project and have done some experiments to better understand its target. Here’s what I found:
failed with an error. Is the main achievement of this project is the successfuly execution of the second command?
2. Translation between LLVM IR and SPIR-V is handled by the SPIRV-LLVM-Translator project, so lowering LLVM IR to SPIR-V is not a part of this project, correct?
AFAIK there is 2 lowering path one of MLIR path and other one is LLVMIR path. @bcardosolopes mentioned that; LLVMIR path is the most focused one, same time MLIR open to contribute. So it looks LLVMIR lowering would be fine.
Yes, hypothetically we could extend the CIR-to-standard-dialects path (and maybe even use the SPIRV dialect), but for this project, the idea is to focus on the CIR-to-LLVM path because that’s more mature right now and will allow us to work closer to the existing OpenCL support in Clang.
Hello @jopperm
I have programming experience in C++ and took a introductory course about compiler in my college. However, I am completely new to GPU programming and working with IR. SPIR V and OPENCL C language are new concepts to me. Am I eligible for this project? Where should I start learning about those concepts?
I’m currently in my third year of Computer Engineering studies in Canada and am keen on contributing to the LLVM open source project. My academic and project experiences have provided me with a solid foundation in computer systems, and I’ve had the opportunity to work directly with LLVM passes and C++. Additionally, my background includes compiler design, both static and dynamic analysis, as well as little bit of understanding on CUDA. I’m particularly excited about the prospect of deepening my understanding of MLIR and ClangIR and am eager to explore how I can contribute to these areas.
Hey @jopperm , I’m highly interested in this project. Having done some research, I believe the objectives are quite clear. However, I do have a design-related question as IR heavily revolves around design considerations after all.
Regarding the desired outcomes, we need to refactor and distribute OpenCL-specific codes within Clang CodeGen (from AST to LLVM IR) between CIRGen and CIRLowering. Could you provide guidance on how to decide which features should be allocated to each stage?
For instance, I’ve observed that CIR performs name mangling directly upon consuming the AST, which isn’t very straightforward. In this project, my belief is that we should adhere as closely as possible to the structure of the original CodeGen. This implies that tasks should predominantly be placed within CIRGen, if I’m not mistaken?
However, in this project I’ve run into similar design dilemmas, such as the emission of OpenCL kernel metadata. It seems odd to emit these SPIR-target-specific metadata immediately, which leaves them in high-level CIR.
Perhaps this is an unusual question, but thanks for reading it.
Thanks for your questions, @seven-mile. I don’t have a fixed design in my head yet, and I think that experimenting and discussing with the community will be a vital and fun part of this project.
In any case, we need to be able to capture all OpenCL-related information coming from the AST in the cir dialect, so yes, extending CIRGen and the dialect to handle different address spaces, calling conventions, etc. is probably where most of the work will take place. Given that OpenCL C is quite similar to C, I hope that the lowering of the extended cir to llvmir will be straightforward. Regarding the name mangling, that should just imitate the existing flow. We’ll have to see if there’s value in doing anything special with the OpenCL builtins in CIR – I suppose in the simplest case, we could just pass them through as cir.calls.
Greetings @jopperm, I wanted to express my gratitude for organizing this exciting project in GSOC. The project looks truly amazing and fascinating, and I wanted to let you know that you can count on my full commitment and dedication to it.
As a final year Bachelor student in Computer Science at UPC (Barcelona), I have been particularly drawn to LLVM, especially ClangIR, due to my bachelor’s final thesis, which involves porting and implementing OpenMP on the novel ClangIR. I have a solid foundation in compiler frontend development and am continuously expanding my knowledge of the middle end and back end. While I am eager to learn more, I already possess a strong understanding of LLVM/MLIR/CLANG and have started making contributions over the past few weeks.
In addition to my experience with LLVM-related technologies, I also have practical experience programming in OpenCL, OpenGL, CUDA, and OPENMP. Thus, this project holds significant appeal to me, and I am confident that I can make valuable contributions given my existing expertise and recent contributions.
I am looking forward to the opportunity to be part of this project and contribute more this summer!
