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

Wed Mar 3 07:36:50 PST 2021

There's definitely some consensus or even roadmap/timeline on this transition missing IMO :)  And pls forgive me my possibly stupid question, but is there any way now to _conveniently_ incorporate MLIR flow for projects which are based on a good old clang->llvm->mir->machinecode way? I understand we have 'llvm' dialect and may recall last year there was a talk about the common C/C++ dialect, but it isn't public yet, is it?

Not that I am aware of, but I haven't followed the most recent development either! We're very interested into looking into this though :)

FYI there was this thread about CIL last month
https://lists.llvm.org/pipermail/cfe-dev/2021-February/067654.html.
It didn’t get a lot of traction yet but I think
this topic could become more interesting to the community in the future. I am not
sure the IR generation in Clang can be completely replaced but CIL could certainly
start as an experimental alternative format that Clang could emit. I do believe it will
take a while until it will catch up with the quality and functionality that IR generation
provides.

Speaking on behalf of the OpenCL community that will greatly benefit from the
SPIR-V generation for OpenCL kernel languages in the LLVM project, having an
LLVM backend would improve the user experience and facilitate many other
improvements in Clang and LLVM for the OpenCL devices that are now blocked on
the unavailability of a common target that vendors without in-tree LLVM backend can
contribute to. The backend will also be the easiest way to integrate with the Clang
frontend because it is a conventional route.

I do acknowledge that MLIR can provide many benefits to the OpenCL community,
however, on the Clang side a different approach than what is available right now
would probably make more sense. It would be better to go via CIL i.e. Clang
would emit CIL flavor of MLIR that would then get converted to the SPIR-V flavor
of MLIR bypassing the LLVM IR. This would be a preferable route but in order to
support CIL for OpenCL we would need to have the support for C/C++ first as it
is just a thin layer on top of the core languages that Clang supports. So this
is not something we can target at the moment because we will likely depend on
the will and the time investment from the C/C++ community for that.

Cheers,
Anastasia
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org>
Sent: 02 March 2021 23:48
To: Aleksandr Bezzubikov <zuban32s at gmail.com>
Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; Trifunovic, Konrad <konrad.trifunovic at intel.com>; aleksandr.bezzubikov at intel.com <aleksandr.bezzubikov at intel.com>
Subject: Re: [llvm-dev] [RFC] Upstreaming a proper SPIR-V backend

On Tue, Mar 2, 2021 at 3:45 PM Aleksandr Bezzubikov <zuban32s at gmail.com<mailto:zuban32s at gmail.com>> wrote:
Please some some comments inlined

On Wed, Mar 3, 2021 at 2:19 AM James Y Knight via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Tue, Mar 2, 2021 at 4:40 PM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Tue, Mar 2, 2021 at 3:07 AM Trifunovic, Konrad via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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.

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.

What do you mean by lower? I'm not that familiar with the way MLIR deals with SPIR-V binaries, but isn't it still necessary to convert SPIR-V dialect to LLVM and then use some hardware-tied codegen to be able to _run_ a SPIR-V binary?

What you're describing seems a bit orthogonal to the SPIRV backend: you're asking "how would someone run a SPIRV binary". That up to the SPIRV runtime implementation (it may or may not use LLVM to JIT the SPIRV to the native platform).
From what I understand, the proposal about a backend here is exclusively about a "LLVM -> SPIRV" flow, i.e. SPIRV is the abstract ISA (like NVPTX) and the final target of the workflow.

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

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

Oh, this sounds interesting actually. Would be nice if someone has any materials or code to share on the topic.

This sort of problem seems like just one of those unfortunate consequences of MLIR being effectively an "LLVM IR 2.0 -- Generic Edition", but not yet actually layered underneath LLVM where it really wants to be. I think it doesn't really make sense to tie this project to those long-term goals of layering MLIR under LLVM-IR, given the extremely long timescale that is likely to occur in. The "proper" solution probably won't be possible any time soon.

There's definitely some consensus or even roadmap/timeline on this transition missing IMO :)  And pls forgive me my possibly stupid question, but is there any way now to _conveniently_ incorporate MLIR flow for projects which are based on a good old clang->llvm->mir->machinecode way? I understand we have 'llvm' dialect and may recall last year there was a talk about the common C/C++ dialect, but it isn't public yet, is it?

Not that I am aware of, but I haven't followed the most recent development either! We're very interested into looking into this though :)

So, in the meantime, we could implement a special-case hack just for SPIRV, to enable lowering it to MLIR-SPIRV dialect. But, what's the purpose? It wouldn't really help move towards the longer term goal, I don't think? And if someone does need that at the moment, they can just feed the SPIRV binary format back into the existing MLIR SPIRV dialect, right?

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<mailto:rengolin at gmail.com>>
> Sent: Tuesday, March 2, 2021 11:12 AM
> To: Trifunovic, Konrad <konrad.trifunovic at intel.com<mailto:konrad.trifunovic at intel.com>>
> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>; Paszkowski, Michal <michal.paszkowski at intel.com<mailto:michal.paszkowski at intel.com>>; Bezzubikov, Aleksandr <aleksandr.bezzubikov at intel.com<mailto:aleksandr.bezzubikov at intel.com>>; Tretyakov, Andrey1 <andrey1.tretyakov at intel.com<mailto: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<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
>
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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/80af52a5/attachment.html>