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

On Tue, 2 Mar 2021 at 09:36, Trifunovic, Konrad via llvm-dev <
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210302/0b58cfd0/attachment.html>

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
>