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

[Neil Henning]

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 )
>     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         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/20150514/e46cf2ad/attachment.html>