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