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

[Chris Bieneman]

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