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

[Mehdi AMINI via llvm-dev]

On Tue, Mar 2, 2021 at 3:07 AM Trifunovic, Konrad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> A very good question. I was actually expecting it 😊
>
> So, at the moment, it does not integrate into MLIR SPIRV backend and we
> have not thought about it. I guess You are referring to having a SPV
> dialect in MLIR and using a 'serialize' option to produce a SPIR-V binary?
>
> I agree that developing two backends in parallel is a bit redundant. If
> SPIR-V LLVM backend becomes a production quality it means actually it could
> consume any LLVM IR (provided it does conform to some SPIR-V restrictions).
> By any LLVM IR input I mean: it should be irrelevant whether it is
> produced by a clang, MLIR to LLVM IR lowering or just some other front-end
> that produces LLVM IR.

The biggest 'impedance mismatch' that I currently see is that SPV MLIR
> dialect is now targeted mostly at Vulkan, while LLVM SPIR-V backend targets
> compute. Besides instruction set, the fundamental difference is a memory
> model.
> So if we want to unify those, we should actually make SPIR-V LLVM backend
> able to produce Vulkan dialect of SPIR-V as well.
>
> My answer is a bit elusive, but I totally agree with Your proposal: we
> should work towards having a one solution, and, LLVM SPIR-V backend seems
> like a more universal one (since it sits lower in the compiler stack).
> My proposal would be to include some MLIR -> LLVM-IR translated code in
> the testing so to have this final goal in mind.
>

Something you're missing here, and maybe Lei clarified but I'll reiterate:
the SPIRV dialect in MLIR is equivalent to what your GlobalISel pass will
produce. It can actually round-trip to/from the SPIRV binary format. So it
is sitting lower than your backend in my view.
I can't figure out a situation where it would make sense to go from MLIR
SPIRV dialect to LLVM to use this new backend, but I may miss something
here...

It would be really great to find a common path here before duplicating a
lot of the same thing in the lllvm-project monorepo, for example being able
to target the MLIR dialect from GlobalISel, or alternatively converting the
MIR to it right after would be an interesting thing to explore.
I haven't seen it, but there was a talk last Sunday on this topic:
https://llvm.org/devmtg/2021-02-28/#vm1



>
> PS: one more thought: SPIR-V does come with a set of builtin/intrinsic
> functions that expose the full capabilities of target architecture (mostly
> GPU). This set of intrinsics is actually a dialect in its own. So this is
> LLVM IR + SPIR-V specific intrinsics and their semantics that fully define
> the SPIR-V dialect at LLVM IR level. I believe this idea could be used in
> MLIR path: MLIR -> LLVM-IR with SPIR-V intrinsics (let's call it a LLVM IR
> SPIR-V dialect) -> SPIR-V binary (generated by a backend). So the idea of
> 'SPIR-V dialect' still exists, it is just now expressed at the LLVM IR
> level.


> regards,
> konrad
>
> > From: Renato Golin <rengolin at gmail.com>
> > Sent: Tuesday, March 2, 2021 11:12 AM
> > To: Trifunovic, Konrad <konrad.trifunovic at intel.com>
> > Cc: llvm-dev at lists.llvm.org; Paszkowski, Michal <
> michal.paszkowski at intel.com>; Bezzubikov, Aleksandr <
> aleksandr.bezzubikov at intel.com>; Tretyakov, Andrey1 <
> andrey1.tretyakov at intel.com>
> > Subject: Re: [llvm-dev] [RFC] Upstreaming a proper SPIR-V backend
> >
> > On Tue, 2 Mar 2021 at 09:36, Trifunovic, Konrad via llvm-dev <mailto:
> llvm-dev at lists.llvm.org> wrote:
> > Hi all,
> >
> > We would like to propose this RFC for upstreaming a proper SPIR-V
> backend to LLVM:
> >
> > Hi,
> >
> > Perhaps a parallel question: how does that integrate with MLIR's SPIRV
> back-end?
> >
> > If this proposal goes through and we have a production-quality SPIRV
> back-end in LLVM, do we remove MLIR's own version and lower to LLVM, then
> to SPIRV? Or do we still need the MLIR version?
> >
> > In a perfect world, translating to LLVM IR then to SPIRV shouldn't make
> a difference, but there could be some impedance mismatch between MLIR->LLVM
> lowering that isn't compatible with SPIRV?
> >
> > But as a final goal, if SPIRV becomes an official LLVM target, it would
> be better if we could iron out the impedance problems and keep only one
> SPIRV backend.
> >
> > cheers,
> > --renato
> >
> _______________________________________________
> 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/20210302/e2c53208/attachment.html>