<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 3:16 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <br>
    <div>On 09/10/2014 02:55 PM, Kevin
      Modzelewski wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Sep 9, 2014 at 9:27 PM,
            Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span>
                  <div><br>
                  </div>
                </span> I'm guessing the key difference in our reasoning
                is about the constant 5.  :)  I'm also guessing that you
                have an example in mind which motivates the need for 5
                to be considered associated with the address range. 
                Could you expand on why?<span><br>
                  <br>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>Can't speak for Dan, but in Pyston we certainly make
              use of these types of constructs to embed JIT-time
              constants (say, an interned string, or a reference to the
              current function object) into the function being compiled.
               Heuristically, we can all see the different of intent
              between "ptr + 5" and "load (int*)0x2aaaaa0000", but it
              seems like it'd be difficult to come up with reasonable
              rules that would separate them.</div>
          </div>
          <br>
        </div>
      </div>
    </blockquote></div></div>
    All of the cases I've seen in JITed code can be dealt with
    differently.  By emitting a global variable and then using the "link
    time" address resolution to map it to the right address, you get the
    same effect while remaining entirely within the well defined part of
    the IR.  I don't see this case as being worth restricting an
    otherwise reasonable optimization.  <br>
    <br>
    One problem with Dan's interpretation of the current rules is that
    this otherwise legal transform becomes problematic:<br>
    %addr = inttoptr 0x2aaaaa0005 to %i32*<br>
    ===><br>
    %tmp = add i32 0x2aaaaa0000, i32 5<br>
    %addr = inttoptr %tmp to %i32*<br>
    <br>
    We probably wouldn't do this at the IR level, but we definitely do
    perform this transform in the backends.  There's no reason it
    *shouldn't* be valid at the IR level either.  <br></div></blockquote><div><br></div><div>I don't quite follow your example here. However, there's a key difference between what happens in the backends and what happens at the mid-level IR: The mid-level IR does serious alias analysis. The backends do a much more limited form of alias analysis, and they supplement it by calling back into the middle-end for the hard stuff. There's no question that a properly formed ptrtoint+add+inttoptr computes the exact same bits as a corresponding getelementptr, on all platforms and in all circumstances. The difference is in the extra aliasing rules that are activated when the getelementptr instruction is used. The backends don't have a reason to preserve those rules, so they don't bother.<br></div></div></div></div>