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

[Sean Silva]

On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> On May 20, 2015, at 7:13 AM, Neil Henning <llvm at duskborn.com> wrote:
>
>  On 20/05/15 08:37, Owen Anderson wrote:
>
>
>  On May 19, 2015, at 7:32 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <resistor at mac.com> wrote:
>
>>
>>  On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com> wrote:
>>
>> 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.
>>
>>
>>  This seems like a terrible reason to choose the architecture of how
>> it’s implemented in LLVM.  The clang driver is part of the LLVM project.
>> If we need to add support for some kind of special SPIR-V flag akin to
>> -emit-llvm, we can do that.  If a particular frontend vendor wants to
>> customize the flags, they can always do so themselves.
>>
>
>  What do you envision as the triple and datalayout when a frontend is
> compiling to SPIR-V?
>
>
>  I’d recommend having its own Triple.  Not that triples are *not* linked
> to targets in LLVM.  My understanding of SPIR-V (and a look through the
> documentation seems to confirm) that it doesn’t specify anything about data
> layouts, presumably because it needs to accommodate both many GPUs with
> varying ideas of what sizes and alignments should be.  If anything this
> pushes me even more strongly that you do *not* want to run SPIR-V-destined
> IR through any more of LLVM (and particularly the CodeGen infrastructure)
> than you have to, since a lot of that will want to bake in DataLayout
> knowledge.
>
>
> At present in SPIR-V we have a decoration for alignment, so a user could
> decorate a type to specify a required alignment (which I would have thought
> in turn would become part of the data layout). Also if we are using a
> non-logical addressing mode the data layout would have a different pointer
> width specified (similar to the SPIR/SPIR64 targets in Clang at present).
> I'll bring it up with the SPIR group at Khronos what the expected behaviour
> of the alignment decoration is in this context, but at present I would say
> it would be legal for an LLVM module that is being turned into SPIR-V to
> have a user-defined data layout.
>
>
> Are we supposed to be able to optimize this IR? I mean is a valid
> use-case: frontend->IR-(optimizer)->IR->SPIRV?
>

I would hope that we would run at least mem2reg/sroa, do those need data
layout?

-- Sean Silva


> I think it has been acknowledged that the optimizer need to be aware of
> the data layout, and that optimizations/transformations that are performed
> on one data layout are not necessarily valid with another one.
>
> If there is not a single blessed data layout for SPIR-V in the spec, and
> the front-end can chose one, it seems to me that it has to be “serialized”
> in SPIR-V as well, isn’t it?
> The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could
> be if the data layout is not specified.
>
> —
> Mehdi
>
>
>
>
>
>     I'm pretty sure that a wide class of frontends for SPIR-V will
> literally be interested in just generating SPIR-V, with no knowledge about
> what the ultimate GPU target is; it is in that sense that they are
> "targeting" SPIR-V. That is, their frontend isn't generating $SPECIFICGPU
> targeted IR, and then being merely asking to have it serialized in a
> specific way (a la -emit-llvm); they are generating IR that is meant to be
> turned into SPIR-V. That is fundamentally different from -emit-llvm (on the
> other hand, it may not be a target; but it sure smells like one).
>
>
>  I completely agree with you… except for the last sentence.
>
>  Honestly, the command line option aspect of this seems like a complete
> red herring to me.  We are talking about adding support to a data format
> which we will need to support both serializing IR to and deserializing IR
> from.  This is exactly the same as the bitcode use case, and not at all
> like the use case of a target.  We should structure the implementation
> according to the ways it will actually be used; rewiring a clang driver
> command line flag to “make it look pretty” is the most trivial part of the
> entire process.
>
>
> So it seems to me that we can at least agree on the location of the
> mainstay of the code - it should reside in lib/SPIRV and be both a reader
> and writer akin to the Bitcode reader/writer pair. Why don't we at Khronos
> work on a patch to tip LLVM that will do that, and then we can revisit how
> a user actually uses our code after that. We should be able to easily
> follow Owen's approach and see how that works out, worst case if it turns
> out to not work it would then be trivial to turn that into a thin backend.
> Seem reasonable?
>
> Cheers,
> -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/20150521/dc2c82a0/attachment.html>