llvm dev - Sep 2012 - [LLVMdev] Proposal: New IR instruction for casting between address spaces

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

On Sep 13, 2012, at 4:55 PM, Chris Lattner <clattner at apple.com> wrote:
> 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.
> 
It depends on what the address space is used for. If I'm logically
partitioning an address space that overlap my pointer size may all be the same
size so this issue doesn't come up other than I know the pointer size are
the same.   My understanding is that is becoming an issue since a pointer type
size could be different for different address space.  I agree for the case where
the pointer size is address space dependent that the client has to understand
the size and the properties to decide if they need to do truncation, sign
extension or zero extensions.

This is a problem for auto upgrade as well.  Today, we have bit cast between
same size pointers for different address space.  We would need to do something
special for auto upgrade here since the proposal is to not allow bit cast
between pointers of different address spaces.

-- Mon Ping

On Sep 13, 2012, at 5:55 PM, Mon Ping Wang <monping at apple.com>
wrote:
>>> 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.
>> 
> 
> It depends on what the address space is used for. If I'm logically
partitioning an address space that overlap my pointer size may all be the same
size so this issue doesn't come up other than I know the pointer size are
the same.
Sure, in that case, use bitcast.
> My understanding is that is becoming an issue since a pointer type size
could be different for different address space.  I agree for the case where the
pointer size is address space dependent that the client has to understand the
size and the properties to decide if they need to do truncation, sign extension
or zero extensions.
Right.
> This is a problem for auto upgrade as well.  Today, we have bit cast
between same size pointers for different address space.  We would need to do
something special for auto upgrade here since the proposal is to not allow bit
cast between pointers of different address spaces.
I haven't followed the details of the proposal, but I think it makes perfect
sense to continue using bitcast for ptr/ptr casts within the same pointer size. 
If you do that, then there is no auto-upgrade issue: all existing bc files can
just be assumed to have the same pointer size.

-Chris