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

[Owen Anderson]

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

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

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150520/b281ed09/attachment.html>