[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

[Philip Reames]

On 09/10/2014 02:55 PM, Kevin Modzelewski wrote:
>
> On Tue, Sep 9, 2014 at 9:27 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>
>     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?
>
>
> 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.
>
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.

One problem with Dan's interpretation of the current rules is that this 
otherwise legal transform becomes problematic:
%addr = inttoptr 0x2aaaaa0005 to %i32*
===>
%tmp = add i32 0x2aaaaa0000, i32 5
%addr = inttoptr %tmp to %i32*

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.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140910/31f9ca2b/attachment.html>