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

>>>>> 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.

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.
-- 
  Ronan KERYELL

On Wed, 3 Mar 2021 at 18:41, Ronan KERYELL <ronan-list at keryell.fr>
wrote:
> 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?

Just thinking out loud if clang couldn't be a hybrid front-end, emitting
LLVM IR and MLIR for different parts of the program (for example,
accelerators), and either use SPIRV (for supported accelerators) or lower
to LLVM IR (for the rest). This would allow us to use MLIR directly in
hybrid programming models (like OpenMP, OpenCL) and make real use of the
high-level optimisations in MLIR. Perhaps SYCL wouldn't fit here.

I'm just going back to the overall goal of MLIR and trying to see on our
current approach, what do we lower too soon to LLVM IR, so it could lower
to MLIR instead, piece wise, then lower to LLVM IR (or not) later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210303/5ab16a43/attachment.html>

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.