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

[Lei Zhang via llvm-dev]

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>