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

[Trifunovic, Konrad via llvm-dev]

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