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

[Aleksandr Bezzubikov via llvm-dev]

Hi,

Perhaps some obvious addition to Konrad's answer - a proper LLVM backend
for SPIR-V can make it much easier for people who're already using LLVM for
codegen purposes (targeting e.g. AArch64 or x86 CPUs) to simply retarget
their flow with one (ideally) option changed in cmdline.


Thanks,
Alex

вт, 2 мар. 2021 г. в 14:07, Trifunovic, Konrad via llvm-dev <
llvm-dev at lists.llvm.org>:

> 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.
>
> 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
>


-- 
Aleksandr Bezzubikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210302/30a59e40/attachment.html>