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

[Mehdi AMINI via llvm-dev]

On Fri, Mar 12, 2021 at 2:30 AM Trifunovic, Konrad via llvm-dev <
llvm-dev at lists.llvm.org> 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
>

To me this is something to look at in the very short term: I'm wary of
investment in duplicated infrastructure for SPIRV binary
serialization/deserialization in-tree. I.e. this covers the path from MIR
(post-GlobalISel)->SPIRV (and potentially any MIR-level transformations).
To be clear: this does not block landing parts of the backend (all the
GlobalISel specification for instance), but I suspect you'll want to get
something end-to-end.

The two points below are indeed more long-term / hypothetical in my
opinion: good to keep in mind but clearly off the table right now.




>         * 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210313/1cbbe85e/attachment.html>