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

[Sean Silva]

On Tue, May 19, 2015 at 9:48 AM, Neil Henning <llvm at duskborn.com> wrote:

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


It actually sort of makes sense to have them somewhere more generic. If you
imagine a GPU driver based on LLVM, where the flow is SPIR-V -> LLVM IR ->
GPU backend, then these intrinsics actually *are* going to filter down into
a backend other than a "SPIR-V backend".

So we have at least two use cases:

1)
Frontend -> LLVM IR -> SPIR-V: primary concern is for the Frontend to
generate LLVM IR that contains a subset of operations suitable for SPIR-V.

2)
SPIR-V -> LLVM IR -> GPU backend: primary concern is just deserializing the
darn thing. Want lib/SPIRV to just be a simple (and fast and no security
vulnerabilities!) way to suck in a buffer of SPIR-V and turn it into a
Module.

It seems that we're getting pretty hung up on whether something in
lib/Target is necessary for various random pieces of machinery for 1). E.g.
in 1) are we compiling with a "spirv triple"? (is something in lib/Target
needed for this?)
In 2) we are definitely not compiling with a spirv triple (actually I
wonder how that will work: when will the triple and datalayout and stuff
get changed...; during the deserialization process?).

-- Sean Silva


>
>  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.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150519/b59ca8b9/attachment.html>