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

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 12 10:57:58 PST 2021

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

More information about the llvm-dev mailing list