<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 1, 2014, at 2:21 PM, Philip Reames <<a href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    <br class="">
    <div class="moz-cite-prefix">On 12/01/2014 11:14 AM, Andrew Trick
      wrote:<br class="">
    </div>
    <blockquote cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      <br class="">
      <div class="">
        <blockquote type="cite" class="">
          <div class="">On Oct 21, 2014, at 4:03 PM, Philip Reames <<a moz-do-not-send="true" href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class=""><span style="font-family: Helvetica; font-size:
              12px; font-style: normal; font-variant: normal;
              font-weight: normal; letter-spacing: normal; line-height:
              normal; orphans: auto; text-align: start; text-indent:
              0px; text-transform: none; white-space: normal; widows:
              auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
              float: none; display: inline !important;" class="">Sanjoy
              made a good point.  We don't actually need a new variant
              of "invariant.start".  Simply using an invariant.start
              with no uses gives us a notion of an invariant region with
              no end.  (Since the result doesn't escape, there can be no
              end hidden inside a function call.)   This seems like a
              simple notion to exploit and is strict step forward from
              where we are, without a new intrinsic.</span></div>
        </blockquote>
      </div>
      <br class="">
      <div class="">
        <div class="">I'm coming back to this because it is a sticking
          point for me in all of the proposals that were floated
          informally on the commits list. I would really like this to
          work, but can't prove that it's safe.</div>
      </div>
    </blockquote>
    As I said in the other thread, !invariant.load and llvm.invariant.*
    are not the same.  This thread is discussing the later, not the
    former.  The other thread is discussing the former, but not the
    later.  <br class="">
    <blockquote cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com" type="cite" class="">
      <div class="">
        <div class=""><br class="">
        </div>
        <div class="">Given:</div>
        <div class=""><br class="">
        </div>
        <div class="">%a = newArray()</div>
        <div class="">%pLen = gep(%a, <length offset>)</div>
        <div class="">invariant.start(<size>, %pLen)</div>
        <div class="">%len = load %pLen</div>
        <div class=""><br class="">
        </div>
        <div class="">%o = foo() // may deallocate %a</div>
        <div class="">store %something</div>
        <div class="">load %o</div>
        <div class=""><br class="">
        </div>
        <div class="">I want to claim that the LLVM optimizer cannot do
          the following (but don't have a complete line of reasoning
          yet):</div>
        <div class=""><br class="">
        </div>
        <div class="">%a = newArray()</div>
        <div class="">%pLen = gep(%a, <length offset>)</div>
        <div class="">invariant.start(<size>, %pLen)</div>
        <div class="">%len = load %pLen</div>
        <div class=""><br class="">
        </div>
        <div class="">%o = foo() // may deallocate %a</div>
        <div class="">if ptrtoint(%o) == ptrtoint(%pLen)</div>
        <div class="">  load %pLen</div>
        <div class="">  store %something // Oops... this might alias</div>
        <div class="">else</div>
        <div class="">  store %something</div>
        <div class="">  load %o</div>
      </div>
    </blockquote>
    Just to make sure we're on the same page, it *would* be legal for
    the optimizer to construct:<br class="">
    <div class="">%a = newArray()</div>
    <div class="">%pLen = gep(%a, <length offset>)</div>
    <div class="">invariant.start(<size>, %pLen)</div>
    <div class="">%len = load %pLen</div>
    <div class=""><br class="">
    </div>
    <div class="">%o = foo() // may deallocate %a</div>
    <div class="">if ptrtoint(%o) == ptrtoint(%pLen)</div>
    <div class="">  store %something // Oops... this might alias<br class="">
        load %pLen <--- This is now after the store<br class="">
    </div>
    <div class="">else</div>
    <div class="">  store %something</div>
    <div class="">  load %o<br class="">
      <br class="">
      Are we in agreement here?  <br class=""></div></div></div></blockquote><div><br class=""></div>It’s fine in the sense that memory access has not been reordered… yet.</div><div><br class=""></div><div>But is there an implicit invariant.end(%pLen) at the call to foo(), at which point the array can be freed and another object allocated in its place? I don’t think so. The way I interpreted the conclusion of this email thread is that invariant.start can be used without invariant.end. Since the token returned by the intrinsic never escapes, you can just assume the memory is invariant at all uses. The problem here is that the optimizer could (in theory) introduce new uses of the pointer after the object lifetime. This is the same problem that you yourself have raised. I hoped we could sidestep the problem because it crops up with any representation that attaches invariance to a pointer value. If we have an answer for this, then we can easily debate other representations like broadening !invariant.load metadata semantics and introducing new intrinsics.</div><div><br class=""></div><div>-Andy</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><div class="">
      <br class="">
      What is the argument that you see leading from the second to your
      problematic example?  I'm missing the reasoning by which you got
      there.  I agree that the example is problematic, I'm just not sure
      how it would arise.  <br class="">
    </div>
    <br class="">
    <br class="">
    <blockquote cite="mid:3C814DCF-2BCF-413A-906F-560B84918529@apple.com" type="cite" class="">
      <div class="">
        <div class=""><br class="">
        </div>
        <div class="">Either we need to make a convincing argument, or
          bail on most of the tentative proposals for expressing
          invariance, and resort to generating IR like this:</div>
        <div class=""><br class="">
        </div>
        <div class="">%a = newArray()</div>
        <div class="">%pLen = gep(%a, <length offset>)</div>
        <div class="">%t = invariant.start(<size>, %pLen)</div>
        <div class="">%len = load %pLen</div>
        <div class=""><br class="">
        </div>
        <div class="">%o = foo() // may deallocate %a</div>
        <div class="">invariant.end(%t, <size>, %pLen)</div>
        <div class="">store %something</div>
        <div class="">load %o</div>
        <div class=""><br class="">
        </div>
        <div class="">...which is pretty painful to implement and may be
          very difficult to optimize.</div>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">-Andy</div>
    </blockquote>
    <br class="">
  </div>

</div></blockquote></div><br class=""></body></html>