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

Wed Mar 3 10:44:41 PST 2021

On Wed, Mar 3, 2021 at 9:25 PM Lei Zhang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

It would be great to hear backend experts' opinions on that, but it seems
that it's more of a problem of producing MLIR with standard LLVM codegen
infra, no matter whether it's SelectionDAG or GlobalISel.

>
>
>
>> 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).
>>
>>
I'm actually wondering what's the point of having a backend for 'spv'
dialect of MLIR rather than some generic 'mir' dialect? The latter may help
in retargeting other backends eventually, which may be perceived as a huge
plus.

> 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
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

Thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210303/177ce524/attachment-0001.html>