[llvm-dev] [SPIR-V] SPIR-V in LLVM

Nicholas Wilson via llvm-dev llvm-dev at lists.llvm.org
Mon May 1 16:43:53 PDT 2017


On 1 May 2017, at 11:53 pm, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

> First of all you may want to review the thread from a few years ago about putting a SPIR-V target into LLVM:

> http://llvm.1065342.n5.nabble.com/RFC-Proposal-for-Adding-SPIRV-Target-td82552.html

Thanks I will take a look.

> The fact that the SPIR-V target translates LLVM IR to SPIR-V directly and
> does not use SelectionDAG/MachineInstrs or any of the standard lowering
> mechanism is a strong case against having it in lib/Target.

Can you even use tablegen as a not target for generating binary format descriptions and intrinsics (serious question)? I think it will require a custom tablegen backend anyway though. One of the primary reasons for being a target is that we can have intrinsics that map directly to core and OpenCL/Vulkan extension instructions, as opposed to the mangling hacks used at the moment, which hurt use by anyone who can’t mangle C++ and windows users because it doesn’t make ANY sense to mangle some stuff as Itanuinm and some stuff as MS.

I am in the process of trying to make it “more traditional” where possible and it makes sense to do so, but I do not fully understand the backend pipeline and am just trying to express the intrinsics and binary format with tablegen at the moment. Regardless of the actual transformation pipeline used I think it should go in target for the advantages stated above, and the one that I missed was, it has its own target triples! Also IIRC the Mill CPUs will/(do?) only use one or two of the backend passes and I can’t imagine them not being considered targets.

>There are
> two solutions for this: have the code live outside of lib/Target or as an
> out-of-tree project(maybe as part of SPIRV-Tools[1]) or rewrite it to use
> the standard lowering mechanism of LLVM.

The first loses the advantages of being a target, the second loses that and the advantages of more eyes of LLVM devs AND staying in sync with the rest of the codebase, not to mention releases! And I can’t see any advantages gained from either of those two possibilities.

>In my opinion, doing LLVM IR->SPIR-V directly is a better option than
>trying to convert it to a proper LLVM target.  SPIR-V is too high level
>to be able to gain any advantage from using LLVM's standard lowering
>mechanism.
>
>You will lose a lot of the type information going through the
>SelectionDAG/MachineInstr layers, which is a major disadvantage.  Also,
>since almost everything is legal in SPIR-V, you won't be getting the
>same kind of advantages from it as other targets.
>
>SPIR-V and LLVM IR are actually fairly similar in terms of what level of the
>compiler stack the were designed for, so I think doing a simple
>LLVM IR -> SPIR-V conversion will be the easiest and give you the best
>results in the the end.

Perhaps, I do not understand the backend pipeline, but that is entirely orthogonal to targethood.

>Also, if you are able to integrate it into SPIR-V Tools you will be able
>to re-use the existing SPIR-V in memory representation and the
>reader/writer APIs.

The in memory representation is already there (inherited from SPIRV-LLVM) and will be refined once the tablegen work is complete, i.e. redundant code removed and integration with the tables.

>I realize that having a separate library will make this more difficult to
>integrate into clang, but there are other targets that use external tools
>for linking/assembling so, you may be able to find a way to write a SPIR-V
>driver for clang that called out to this external tool for the
>LLVM IR -> SPIR-V phase.

An external library looks to get the worst of all worlds. I have no interest in clang, as my work is for LDC. The external library approach would require me writing a driver for LDC and then someone else writing a driver for clang, duplicating both code AND effort/bug fixes across multiple projects. There is already enough to do w.r.t metadata for the producer without having to alter their compilation pipeline as well. I plan to reduce the dependance on metadata as much as possible, but still.


Nic

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170501/5e790780/attachment-0001.html>


More information about the llvm-dev mailing list