<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 6:11 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13 May 2015, at 13:56, Liu, Yaxun (Sam) <<a href="mailto:Yaxun.Liu@amd.com">Yaxun.Liu@amd.com</a>> wrote:<br>
><br>
> Khronos Group SPIR WG is working on a bi-way converter between LLVM bitcode and SPIR-V (<a href="https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf" target="_blank">https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf</a> ) binary and is willing to upstream it to the LLVM project.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span class=""><br>
> For the SPIR-V to LLVM converter, we are seeking suggestions on its proper location in the LLVM project.<br>
<br>
</span>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).<br></blockquote><div><br></div><div>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)?</div></div></div></div>