<div dir="ltr">LLVM doesn't appear to respect this.<div><br></div><div>consider:</div><div><div>target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"</div><div><br></div><div>define i8* @h(i8* %x, i8* %y) {</div><div> %pti = ptrtoint i8* %y to i64</div><div> %sub = sub i64 0, %pti</div><div> %gep = getelementptr i8* %x, i64 %sub</div><div> ret i8* %gep</div><div>}</div></div><div><br></div><div>run it with -instcombine and we get:</div><div><div><br></div><div>define i8* @h(i8* %x, i8* %y) {</div><div> %pti = ptrtoint i8* %y to i64</div><div> %1 = ptrtoint i8* %x to i64</div><div> %2 = sub i64 %1, %pti</div><div> %gep = inttoptr i64 %2 to i8*</div><div> ret i8* %gep</div><div>}</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 6: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">
<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"><span class="">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>
</span><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>
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><span class="HOEnZb"><font color="#888888">
<br>
Philip<br>
<br>
</font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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>
<br></blockquote></div><br></div>