<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1 to lib/Target/SPIRV/(Reader|Writer)<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">I’m really excited to see this moving forward!</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 14, 2015, at 1:56 AM, Neil Henning <<a href="mailto:llvm@duskborn.com" class="">llvm@duskborn.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hey Reid,<br class="">
<br class="">
(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 :)<br class="">
<br class="">
-Neil.<br class="">
<br class="">
<div class="moz-cite-prefix">On 13/05/15 18:32, Reid Kleckner wrote:<br class="">
</div>
<blockquote cite="mid:CACs=tyJcvmNhZC9FdxFEPpX6v07V3ftjAK36K8gbFXz+Pq9kFQ@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, May 13, 2015 at 6:11 AM,
David Chisnall <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" class="">David.Chisnall@cl.cam.ac.uk</a>></span>
wrote:<br class="">
<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 moz-do-not-send="true" href="mailto:Yaxun.Liu@amd.com" class="">Yaxun.Liu@amd.com</a>>
wrote:<br class="">
><br class="">
> Khronos Group SPIR WG is working on a bi-way
converter between LLVM bitcode and SPIR-V (<a moz-do-not-send="true" href="https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf" target="_blank" class="">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 class="">
><br class="">
> 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 class="">
><br class="">
> 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 class="">
<br class="">
</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 class="">
<span class=""><br class="">
> For the SPIR-V to LLVM converter, we are seeking
suggestions on its proper location in the LLVM project.<br class="">
<br class="">
</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 class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">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>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></div></body></html>