[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

Neil Henning
2015-05-19T16:48:31Z

Answers to Owen;
>> There are things in SPIR-V that are not representable by the LLVM IR,
so we'd have to add SPIR-V specific intrinsics for this (again making the
case for having it as a target more palatable),
> Why does that motivate it being a target?  Intrinsics do not have to be
linked to a target.
My motivation here is that a target would give us a nice logical
separation - EG. these intrinsics only work with the SPIR-V target and
there is no way you should be calling them from any other context. I
really didn't think people would want us to add a bunch of intrinsics to
Intrinsics.td.
>> and also there are things in the IR that won't be allowed when
producing SPIR-V (off the top of my head, in a graphics shader with logical
addressing mode a ton of pointer use is banned).
> Again, why does that motivate it being a target?  No amount of legalization
can define away fundamentally unsupported major constructs.
>
> More generally,  making it a target immediately invokes a lot of behavior
that is undesirable for a serialization format between a fronted and a backend.
You don’t *want* LLVM to do a lot of wacky CodeGenPrepare and/or lowering before
emitting SPIR-V, which is likely to lose source-level information that the
eventual consumer wanted to have available.  You do not want to leverage any of
the general target architecture.
>
> I really don’t see any strong reason for it to be a target at all, and all
the use cases I can see for it are exactly the same as the use cases for LLVM
bitcode, with a  “for graphics” qualifier tacked on.
My idea was that this would be backend ala the CppBackend, it would
essentially just be a ModulePass that calls the lib/SPIRV/*Writer.cpp
code. The 'backend' in this context is purely so that we can then enable
Clang to target SPIR-V in the same consistent manner to all the other
targets it supports.

As Chris said;

> There are two different things going on here:
>
> 1) Where the code lives in the llvm tree.
> 2) How clang and other tools expose it to users.
>
> Per #1, it is pretty clear to me that this is a serialization format and
should be structured like the bitcode reader & writer.  It is not a target,
though maybe it also need a minimal target (but not instruction selection tables
etc) so that clang and other tools can generate code for it.

Is exactly what I thought we'd end up with.

-Neil.