[llvm-dev] [RFC] Upstreaming a proper SPIR-V backend (original) (raw)

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 3 11:02:26 PST 2021

On 3/3/21 12:41 PM, Ronan KERYELL via llvm-dev wrote:

On Wed, 3 Mar 2021 11:24:45 +0000, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> said: Renato> While Clang will take a long time (if ever) to generate MLIR Renato> for C/C++, it could very well generate MLIR for non-C++ Renato> (OpenCL, OpenMP, SYCL, etc) which is then optimised, Renato> compiled into LLVM IR and linked to the main module (or not, Renato> for multi-targets) after high-level optimisations. Actually SYCL is pure C++, just with a few special C++ classes similar to some other special things like std::thread or setjump()/longjump(). OpenMP, when associated to C++, is also pure C++. In your list OpenCL is a language based on C/C++ to program accelerators while SYCL & OpenMP are single-source frameworks to program full applications using a host and some accelerators, with both part in the same source program in a seamless and type-safe way. So the MLIR approach is quite compelling with its "Multi-Level" representation of both the host and the device code to enable multi-level inter-procedural or inter-module optimizations which cannot be done today when compiling single-source OpenMP/SYCL/CUDA/HIP/OpenACC because most implementations use early outlining of the device code, thus it is super hard to do inter-module optimization later without a multi-level view.

FWIW, the indirection "caused by" early outlining is already covered with callbacks in LLVM-IR. The separation of host and device code will be covered with heterogeneous LLVM-IR modules.

"Super hard" is definitively not how I would describe it given our current state, we mainly need to put the things together.

~ Johannes

As you and most other people said, it looks we are stuck with plain LLVM for a while. But perhaps you were considering in your sentence the case where with OpenMP/SYCL/CUDA/HIP you generate LLVM for the host code part and MLIR just for the hardware accelerator parts? While it would obviously allow to recycle more easily the MLIR SPIR-V generator, it would still require somehow to generate MLIR from the C++ accelerator parts. At least the C++ code allowed in accelerator parts is often restricted, so it is easier to do than with full-fledged host part C++ and actually there are a few hacks trying to do this (for example leveraging Polly, PPCG...). But it seems we are far from a production-quality infrastructure yet. So it looks like, while we do not have a robust C++ to MLIR path, we need an LLVM IR to SPIR-V path somehow. At least, as others like Mehdi said, let's do good software engineering and factorize out as much as we can between the LLVM IR and MLIR paths.

More information about the llvm-dev mailing list