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