<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 8:03 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On May 20, 2015, at 7:13 AM, Neil Henning <<a href="mailto:llvm@duskborn.com" target="_blank">llvm@duskborn.com</a>> wrote:</div><br><div>
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    On 20/05/15 08:37, Owen Anderson wrote:<br>
    <blockquote type="cite">
      
      <br>
      <div>
        <blockquote type="cite">
          <div>On May 19, 2015, at 7:32 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div>
          <br>
          <div>
            <div dir="ltr"><br>
              <div class="gmail_extra"><br>
                <div class="gmail_quote">On Tue, May 19, 2015 at 4:05
                  PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>></span> wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <div style="word-wrap:break-word"><span><br>
                        <div>
                          <blockquote type="cite">
                            <div>On May 19, 2015, at 9:48 AM,
                              Neil Henning <<a href="mailto:llvm@duskborn.com" target="_blank">llvm@duskborn.com</a>>
                              wrote:</div>
                            <br>
                            <div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">The 'backend' in this context
                                is purely so that we can then enable
                                Clang to target SPIR-V in the same
                                consistent manner to all the other
                                targets it supports.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
                            </div>
                          </blockquote>
                        </div>
                        <br>
                      </span>
                      <div>This seems like a terrible reason to
                        choose the architecture of how it’s implemented
                        in LLVM.  The clang driver is part of the LLVM
                        project.  If we need to add support for some
                        kind of special SPIR-V flag akin to -emit-llvm,
                        we can do that.  If a particular frontend vendor
                        wants to customize the flags, they can always do
                        so themselves.</div>
                    </div>
                  </blockquote>
                  <div><br>
                  </div>
                  <div>What do you envision as the triple and
                    datalayout when a frontend is compiling to SPIR-V?</div>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>I’d recommend having its own Triple.  Not that triples are
          *not* linked to targets in LLVM.  My understanding of SPIR-V
          (and a look through the documentation seems to confirm) that
          it doesn’t specify anything about data layouts, presumably
          because it needs to accommodate both many GPUs with varying
          ideas of what sizes and alignments should be.  If anything
          this pushes me even more strongly that you do *not* want to
          run SPIR-V-destined IR through any more of LLVM (and
          particularly the CodeGen infrastructure) than you have to,
          since a lot of that will want to bake in DataLayout knowledge.</div>
      </div>
    </blockquote>
    <br>
    At present in SPIR-V we have a decoration for alignment, so a user
    could decorate a type to specify a required alignment (which I would
    have thought in turn would become part of the data layout). Also if
    we are using a non-logical addressing mode the data layout would
    have a different pointer width specified (similar to the SPIR/SPIR64
    targets in Clang at present). I'll bring it up with the SPIR group
    at Khronos what the expected behaviour of the alignment decoration
    is in this context, but at present I would say it would be legal for
    an LLVM module that is being turned into SPIR-V to have a
    user-defined data layout.<br></div></div></blockquote><div><br></div></span><div>Are we supposed to be able to optimize this IR? I mean is a valid use-case: frontend->IR-(optimizer)->IR->SPIRV?</div></div></div></blockquote><div><br></div><div>I would hope that we would run at least mem2reg/sroa, do those need data layout?</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>I think it has been acknowledged that the optimizer need to be aware of the data layout, and that optimizations/transformations that are performed on one data layout are not necessarily valid with another one.</div><div><br></div><div>If there is not a single blessed data layout for SPIR-V in the spec, and the front-end can chose one, it seems to me that it has to be “serialized” in SPIR-V as well, isn’t it?</div><div>The round-trip SPIR-V -> IR -> SPIR-V does not sound as usuful as it could be if the data layout is not specified.</div><div><br></div><div>— </div><span class="HOEnZb"><font color="#888888"><div>Mehdi</div><div><br></div><div><br></div><div><br></div><br></font></span><blockquote type="cite"><div><span class=""><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <blockquote type="cite">
      <div>
        <blockquote type="cite">
          <div>
            <div dir="ltr">
              <div class="gmail_extra">
                <div class="gmail_quote">
                  <div>I'm pretty sure that a wide class of
                    frontends for SPIR-V will literally be interested in
                    just generating SPIR-V, with no knowledge about what
                    the ultimate GPU target is; it is in that sense that
                    they are "targeting" SPIR-V. That is, their frontend
                    isn't generating $SPECIFICGPU targeted IR, and then
                    being merely asking to have it serialized in a
                    specific way (a la -emit-llvm); they are generating
                    IR that is meant to be turned into SPIR-V. That is
                    fundamentally different from -emit-llvm (on the
                    other hand, it may not be a target; but it sure
                    smells like one).</div>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        I completely agree with you… except for the last sentence.</div>
      <div><br>
      </div>
      <div>Honestly, the command line option aspect of this seems like a
        complete red herring to me.  We are talking about adding support
        to a data format which we will need to support both serializing
        IR to and deserializing IR from.  This is exactly the same as
        the bitcode use case, and not at all like the use case of a
        target.  We should structure the implementation according to the
        ways it will actually be used; rewiring a clang driver command
        line flag to “make it look pretty” is the most trivial part of
        the entire process.</div>
    </blockquote>
    <br>
    So it seems to me that we can at least agree on the location of the
    mainstay of the code - it should reside in lib/SPIRV and be both a
    reader and writer akin to the Bitcode reader/writer pair. Why don't
    we at Khronos work on a patch to tip LLVM that will do that, and
    then we can revisit how a user actually uses our code after that. We
    should be able to easily follow Owen's approach and see how that
    works out, worst case if it turns out to not work it would then be
    trivial to turn that into a thin backend. Seem reasonable?<br>
    <br>
    Cheers,<br>
    -Neil.<br>
  </div></span><span class="">

_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div></div>