<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Nov 20, 2014, at 5:20 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=utf-8" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    <br class="">
    <div class="moz-cite-prefix">On 11/20/2014 04:36 PM, Pete Cooper
      wrote:<br class="">
    </div>
    <blockquote cite="mid:564B0104-674B-41D0-8C8A-E026D78C7097@apple.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      Hi Philip
      <div class=""><br class="">
      </div>
      <div class="">I added invariant.load in this commit: <a moz-do-not-send="true" href="http://llvm.org/viewvc/llvm-project?view=revision&revision=150257" class="">http://llvm.org/viewvc/llvm-project?view=revision&revision=150257</a></div>
      <div class=""><br class="">
      </div>
      <div class="">I’m not arguing against the changes you are
        proposing, but I just wanted to give some clarification on the
        original intention of this metadata, just incase that changes
        things.</div>
      <div class=""><br class="">
      </div>
      <div class="">So in Objective-C, globals such as
        “*SELECTOR_REFERENCES*” are initialized once, by the runtime.
         They are then essentially constant.  Unfortunately they aren’t
        compile time constants or we could just put them in the
        appropriate section.</div>
      <div class=""><br class="">
      </div>
      <div class="">This metadata was meant to solve exactly this
        situation, but never considered for any others.  In particular,
        its undefined behavior in Objective-C if anyone did chase
        pointers through the runtime and find a way to modify one of
        these.  It’s therefore never expected that you’ll see a store,
        call, or anything else, in any way modify one of these.</div>
    </blockquote>
    Makes sense.  Just to be clear, did you intend for invariant.load to
    imply that the address of the selector variable was always
    dereferenceable?  The current *implementation* doesn't seem to
    assume that, but what's the history?<br class=""></div></div></blockquote>In every example I ever saw, the address was actually a @global so was always dereferencable..  I guess i would be possible to have a PHI over selector references and then you aren’t pointing directly at a global, but the load was always assumed to read from a global one way or another.<br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
    <blockquote cite="mid:564B0104-674B-41D0-8C8A-E026D78C7097@apple.com" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class="">TBH this metadata is probably the wrong thing for
        selector references, or at least its name is.  What we really
        needed was some way to describe 'externally initialized once
        before first use’ which implies that its always invariant
        anyway.  That just never occurred to me at the time of writing.</div>
    </blockquote>
    I'm trying to figure out how to support "initialized once (in
    visible IR) before first use".  The goal of this thread is really
    just to clarify what the current semantics are.  I think the current
    semantics actually implement both; I'm just trying to confirm this. 
    <br class=""></div></div></blockquote>Agreed.  I think they do implement both right now.</div><div><br class=""></div><div>Thanks,</div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
    <br class="">
    <br class="">
    <blockquote cite="mid:564B0104-674B-41D0-8C8A-E026D78C7097@apple.com" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class="">Thanks,</div>
      <div class="">Pete<br class="">
        <div class="">
          <blockquote type="cite" class="">
            <div class="">On Nov 20, 2014, at 4:25 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=""><br class="">
              On 11/20/2014 04:14 PM, Sanjoy Das wrote:<br class="">
              <blockquote type="cite" class="">
                <blockquote type="cite" class="">To clarify that the
                  invariant nature of a given pointer does not preclude
                  the modification of that location through a pointer
                  which is unrelated to the load operand. In particular,
                  initializing a location and then passing a pointer
                  through an opaque intrinsic which produces a new
                  unrelated pointer, should behave as expected provided
                  that the intrinsic is memory dependent on the
                  initializing store.<br class="">
                </blockquote>
                Does this mean you cannot common loads for escaped
                memory over calls?  The call could have modified the
                pointed-to location using another pointer.<br class="">
              </blockquote>
              No, it does not.  The optimizer is free to assume that the
              location as seen through *this* pointer is invariant.
               Whether another copy of the pointer escaped is irrelevant
              to that assumption.  The call may contain a "potentially
              aliasing store" in my proposed wording.<br class="">
              <br class="">
              The scheme I was trying to describe in my clarification
              (not LangRef wording!) was this:<br class="">
              %p = ...<br class="">
              store i32 5, i32* %p<br class="">
              %p2 = call i32* @opaque_call(i32* %p)<br class="">
              %v = load i32* %p2, !invariant !{}<br class="">
              <br class="">
              The fact that %p and %p2 might happen to be the same
              location is irrelevant to the fact that the location as
              seen by %p2 is invariant and the location as seen by %p is
              not.  In this case, I would expect the load from %p2 to
              see the value stored to %p, but that's only because the
              optimizer can't provide that %p == %p2.  If it could, then
              the value of the load is unclear.  (5, or whatever value
              that field had before...)<br class="">
              <br class="">
              <blockquote type="cite" class=""><br class="">
                <a moz-do-not-send="true" href="http://reviews.llvm.org/D6346" class="">http://reviews.llvm.org/D6346</a><br class="">
                <br class="">
                <br class="">
              </blockquote>
              <br class="">
              _______________________________________________<br class="">
              llvm-commits mailing list<br class="">
              <a moz-do-not-send="true" href="mailto:llvm-commits@cs.uiuc.edu" class="">llvm-commits@cs.uiuc.edu</a><br class="">
              <a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br class="">
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
    <br class="">
  </div>

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