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

>> 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...
By 'lower' I was referring to the place of backend in a typical compiler
flow that I could imagine: MLIR -> LLVM-IR (opt) -> Bakcend (llc).
And yes, I agree, if we treat MLIR SPV dialect as a final result of what this
backend would produce, then MLIR SPV could be the lowest-level representation
(before streaming into SPIR-V binary).
> 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
We should investigate that. I believe though that GlobalISel is not really that
flexible to produce MLIR (or dialects) - but that is something we might want to
change 😊 That path would open us a door to have a great deal of unification:
We can support two 'entry points' : 
1) Directly through MLIR. It gets translated to SPV dialect, and then streamed
to SPIR-V binary. (without even going into LLVM-IR)
2) Start with LLVM-IR (with some augmented metadata and intrinsics). Feed that
into proposed SPIR-V backend. Backend will produce MLIR SPV dialect and make use
of whatever legalization/binary emission/etc. it provides.
This way, SPIR-V LLVM backend will be (a probably tiny) wrapper around MLIR SPV.
Then, the majority of work would focus on MLIR SPV (e.g. adding support for
OpenCL environment in addition to existing Vulkan compute).

From the implementation point of view, that would bring us huge re-use. Still,
from the design point of view, we need to maintain two 'GPU centric'
representations': LLVM-IR with SPIR-V intrinsics/metadata/attributes + MLIR
SPV dialect.
Still that would be a much better situation from the community point of view.

--
konrad

On Wed, Mar 3, 2021 at 8:25 AM Trifunovic, Konrad via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> >> 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...
>
> By 'lower' I was referring to the place of backend in a typical
compiler
> flow that I could imagine: MLIR -> LLVM-IR (opt) -> Bakcend (llc).
> And yes, I agree, if we treat MLIR SPV dialect as a final result of what
> this backend would produce, then MLIR SPV could be the lowest-level
> representation (before streaming into SPIR-V binary).
>
> > 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
>
> We should investigate that. I believe though that GlobalISel is not really
> that flexible to produce MLIR (or dialects) - but that is something we
> might want to change 😊 That path would open us a door to have a great deal
> of unification:
>
+1. This sounds quite interesting and worth exploration. Starting with some
initial feasibility/blockers investigation would be awesome. It's also not
scoped to SPIR-V per se; done right it actually can have the ability to
connect any MLIR dialect I guess? (So later we can design other dialects
for LLVM CodeGen probably.) Connecting LLVM and MLIR is a huge effort. And
it needs to start somewhere. This might be a nice first attempt? (Please
pardon me if this is obviously not; I'm not super familiar with GlobalISel
infrastructure.)

> We can support two 'entry points' :
> 1) Directly through MLIR. It gets translated to SPV dialect, and then
> streamed to SPIR-V binary. (without even going into LLVM-IR)
> 2) Start with LLVM-IR (with some augmented metadata and intrinsics). Feed
> that into proposed SPIR-V backend. Backend will produce MLIR SPV dialect
> and make use of whatever legalization/binary emission/etc. it provides.
> This way, SPIR-V LLVM backend will be (a probably tiny) wrapper around
> MLIR SPV. Then, the majority of work would focus on MLIR SPV (e.g. adding
> support for OpenCL environment in addition to existing Vulkan compute).
>
> From the implementation point of view, that would bring us huge re-use.
> Still, from the design point of view, we need to maintain two 'GPU
centric'
> representations': LLVM-IR with SPIR-V intrinsics/metadata/attributes +
MLIR
> SPV dialect.
> Still that would be a much better situation from the community point of
> view.
>
> --
> konrad
>
>
>
>
>
> _______________________________________________
> 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/20210303/4d20a49b/attachment.html>