[LLVMdev] Proposal: New IR instruction for casting between address spaces

Chris Lattner clattner at apple.com
Thu Sep 13 14:23:55 PDT 2012

On Sep 13, 2012, at 12:00 PM, Mon Ping Wang <monping at apple.com> wrote:
>>> In C, integer to point conversions are implementation defined and
>>> depends on what the addressing structure of the execution environment
>>> is. Given the current definition of ptrtoint and intoptr, I feel that
>>> the addressing structure feels like a flat memory model starting from 0
>>> and the value "b" should be 65529.  In your example where we know the
>>> largest pointer is 64b, I would expect the final result to be the same
>>> as doing a ptrtoint from int(1) to i64 and intotptr to int(2)*.
>> [Villmow, Micah] So then if there is already a way to do this, what really is the benefit of adding a new instruction? 
>> Also there is a typo in my example, the second assignment should not have the '*'. I can add a new instruction if that
>> is the recommended behavior, but I think it would also be fine to force ptrtoint and inttoptr, although it does take one instruction more.
> The problem with using ptrtoint and inttoptr is that one has to pick an intermediate integer type that is safe to convert to and from.  Since the pointer size is target dependent, it seems unnatural to use ptrtoint and inttoptr for that.  

If we were to add first class support for this, we'd have to add three new instructions: trunc_ptr, sext_ptr, and zext_ptr, all of which would be used for pointer to pointer conversions.

Why is it so bad to use ptrtoint/inttoptr with some large-enough integer size?  Neither solution avoids exposing target information into IR.


More information about the llvm-dev mailing list