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

[Neil Henning]

On 20/05/15 08:37, Owen Anderson wrote:
>
>> On May 19, 2015, at 7:32 PM, Sean Silva <chisophugis at gmail.com 
>> <mailto:chisophugis at gmail.com>> wrote:
>>
>>
>>
>> On Tue, May 19, 2015 at 4:05 PM, Owen Anderson <resistor at mac.com 
>> <mailto:resistor at mac.com>> wrote:
>>
>>
>>>     On May 19, 2015, at 9:48 AM, Neil Henning <llvm at duskborn.com
>>>     <mailto: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.

>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150520/eaaee836/attachment.html>