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

[Chris Lattner]

On Sep 13, 2012, at 3:53 PM, Mon Ping Wang <monping at apple.com> wrote:
>>> 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.
>> 
> 
> The pointer size is target dependent so it seems strange to choose an arbitrary size to convert to and from. Are you making a practical argument that 64b is sufficient on all machines so all targets can use that?  In other words, pointers > 64 doesn't make any sense in terms of the address space? (A pointer to be > 64 if clients want to use some upper bits to track some state I guess). 
> 
> In terms of the three new instructions, one could argue that ptrtoint and intoptr has the same issue or those can also explode in a similar way.  To use them, this seems target dependent so unless we really want to support all the various addressing structures, I rather not have them.

My point is that any producer of this sort of pointer cast is already necessarily target specific (it is generating target-specific address space numbers!).  If the front-end knows the address space to use, it can know a safe integer size to use.

-Chris