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

David Majnemer
Thu, 21 May 2015 21:59:08 -0000

On Thu, May 21, 2015 at 1:50 PM, Sean Silva <chisophugis at gmail.com>
wrote:

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

SROA assumes that it has DataLayout.


>
> -- 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
>>
>>
>>
>
> _______________________________________________
> 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/c6541c1b/attachment.html>