+1 to lib/Target/SPIRV/(Reader|Writer)
I really like this idea. I’ve talked with some people on both the LLVM and
Khronos sides and I really think adding SPIR-V support to LLVM as an optional
program serialization format would be fantastic. I think it would make it even
easier for LLVM-based tools to be integrated into GPU authoring and execution
pipelines.
I’m really excited to see this moving forward!
-Chris
> On May 14, 2015, at 1:56 AM, Neil Henning <llvm at duskborn.com>
wrote:
>
> Hey Reid,
>
> (Donning my Khronos hat here) - it would make sense to keep the code
together within a SPIRV backend, in that there are many helper constructs shared
by both the reader/writer - we realised though that this would be a non-standard
thing to do in terms of LLVM as it stands (EG. we have a backend that also has
code that can consume SPIR-V and spit out LLVM IR!), so I am happy that you have
suggested it :)
>
> -Neil.
>
> On 13/05/15 18:32, Reid Kleckner wrote:
>> On Wed, May 13, 2015 at 6:11 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>> On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com
<mailto:Yaxun.Liu at amd.com>> wrote:
>> >
>> > Khronos Group SPIR WG is working on a bi-way converter between
LLVM bitcode and SPIR-V
(https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf
<https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf> ) binary and
is willing to upstream it to the LLVM project.
>> >
>> > The bi-way converter uses a common in-memory representation of
SPIR-V. It works by breaking down a module to instructions and construct the
translated module in memory then output it. Currently it supports SPIR-V common
instructions and OpenCL specific instructions. Supporting of other languages is
under consideration.
>> >
>> > We plan to refactor the LLVM to SPIR-V converter as a backend at
llvm/lib/Target/SPIRV to allow Clang targeting SPIR-V. Since this will result in
an unconventional backend which does not use SelectionDAG/MC, we would like to
know whether it is acceptable. We are open to the SelectionDAG/MC approach if
the community recommends it.
>>
>> I believe that the ‘how to write a backend’ documentation recommends
against using SelectionDAG for generating code for other virtual instruction
sets. I don’t think that there’s any benefit to forcing a back end to use the
generic infrastructure, unless it makes sense for that back end to do so.
>>
>> > For the SPIR-V to LLVM converter, we are seeking suggestions on
its proper location in the LLVM project.
>>
>> To me, this is no different from any other front end, so should
probably live in a separate repository (though ideally an LLVM-hosted one that
is integrated with buildbots and kept up to date).
>>
>> Honestly, SPIR-V seems a little bit more like a quirky program
serialization format. It's not a source language or an ISA. It might be
better to treat it like the bitcode reader/writer and have both in one place.
Something like lib/Target/SPIRV/(Writer|Reader)?
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<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/20150515/345c61aa/attachment.html>