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

[Johannes Doerfert via llvm-dev]

On 3/12/21 4:30 AM, Trifunovic, Konrad via llvm-dev wrote:
> 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?

The first point sounds good, let's start there and revisit the rest as 
it becomes
interesting, no need to finalize anything as the context is arguably fluid.

----

FWIW, the other three points sounds very much like "MLIR is obviously 
the solution,
let's switch everything over so our problems are somehow solved". If I 
were you I
would not want to be the first to do the LLVM-IR -> MLIR dialect code 
path. If there
is one, adding SPIR-V support is something one can look at, I'd expect 
pros, cons,
and a lot of unforeseen complications.

My point two, if any, would be to lower some parts of the SPIR-V dialect 
to LLVM-IR
(+ the extensions you are adding anyway for point one). That seems like 
a low-cost
way to determine if a single SPIR-V backend (in LLVM-Core) would make 
sense or not.

~ Johannes


>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev