[llvm-dev] [RFC] Upstreaming a proper SPIR-V backend

[Johannes Doerfert via llvm-dev]

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.