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

>>>>> On Wed, 3 Mar 2021 18:57:33 +0000, Renato Golin
<rengolin at gmail.com> said:
    Renato> Just thinking out loud if clang couldn't be a hybrid
    Renato> front-end, emitting LLVM IR and MLIR for different parts of
    Renato> the program (for example, accelerators), and either use
    Renato> SPIRV (for supported accelerators) or lower to LLVM IR (for
    Renato> the rest).

At some point everything is possible.

    Renato> This would allow us to use MLIR directly in hybrid
    Renato> programming models (like OpenMP, OpenCL) and make real use
    Renato> of the high-level optimisations in MLIR. Perhaps SYCL
    Renato> wouldn't fit here.

I guess you have exchanged the words OpenCL and SYCL in this sentence.
OpenCL is like graphics shader languages: a foreign language to the
host. From the host point-of-view it is just a host foreign API managing
memory allocation on the device and controlling kernel execution on some
devices (think RPC). The advantage is that you can use OpenCL from a
COBOL host program if you want but this is another story... :-)
-- 
  Ronan KERYELL

Hi,

Thank you all for a very in-depth discussion so far.
Besides the major topic of MLIR and LLVM-IR coexistence, are there any other
comments, especially regarding 'Open questions' section that we
proposed?

My recap so far is:
	* There is a good reception from the community that is interested in LLVM-IR
path (a classical FE/opt/code-generation path, clang community)
	* There is a concern on maintenance cost if we have two solutions in parallel:
MLIR based, and LLVM-IR based. We will look for the ways to address this, one
investigation point would be generating MLIR 'spv' dialect from the
target backend infrastructure (GlobalISel)
	* We also need to iron out the details of the semantics and capabilities of
SPIR-V that we would like to expose: 1) which exact subset of LLVM-IR is
acceptable by the backend, 2) how do we expose the extensions and core builtins,
3) how do we map a memory model to LLVM-IR (especially if we think about adding
Vulkan compute memory model) etc.

Based on the feedback so far, that would be roughly my plan:
	* Go ahead with a SPIR-V backend in LLVM-IR, as planned. Look for clang
integration.
	* Midterm: investigate MLIR 'spv' dialect generation from GlobalISel
(or other means) as an unifying solution
	* Long-term: come up with a single, MLIR based backend (which is going to take
care of serialization, deserialization, automatic specification updates and all
the rest of the infrastructure work). This still means we will have two entry
points: directly through MLIR 'spv' dialect or through LLVM-IR with
intrinsics/metadata. Will support both Vulkan compute and OpenCL compute models.
	* When/if clang eventually switches to MLIR code generation, that would be
eventually the end of LLVM-IR path :)

For the first point, we need a close collaboration with GlobalISel and clang
communities. For the last three points, we will work closely with MLIR community
on engineering and IR specification.

What do You think? Does this sound like a reasonable plan?

thanks,
konrad
> -----Original Message-----
> From: Ronan KERYELL <ronan at keryell.fr>
> Sent: Wednesday, March 3, 2021 8:55 PM
> To: Renato Golin <rengolin at gmail.com>
> Cc: Renato Golin via llvm-dev <llvm-dev at lists.llvm.org>;
Trifunovic, Konrad
> <konrad.trifunovic at intel.com>
> Subject: Re: [llvm-dev] [RFC] Upstreaming a proper SPIR-V backend
> 
> >>>>> On Wed, 3 Mar 2021 18:57:33 +0000, Renato Golin
> <rengolin at gmail.com> said:
> 
>     Renato> Just thinking out loud if clang couldn't be a hybrid
>     Renato> front-end, emitting LLVM IR and MLIR for different parts of
>     Renato> the program (for example, accelerators), and either use
>     Renato> SPIRV (for supported accelerators) or lower to LLVM IR (for
>     Renato> the rest).
> 
> At some point everything is possible.
> 
>     Renato> This would allow us to use MLIR directly in hybrid
>     Renato> programming models (like OpenMP, OpenCL) and make real use
>     Renato> of the high-level optimisations in MLIR. Perhaps SYCL
>     Renato> wouldn't fit here.
> 
> I guess you have exchanged the words OpenCL and SYCL in this sentence.
> OpenCL is like graphics shader languages: a foreign language to the host.
> From the host point-of-view it is just a host foreign API managing memory
> allocation on the device and controlling kernel execution on some devices
> (think RPC). The advantage is that you can use OpenCL from a COBOL host
> program if you want but this is another story... :-)
> --
>   Ronan KERYELL