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

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.

-Chris

> -----Original Message-----
> From: Chris Lattner [mailto:clattner at apple.com]
> Sent: Thursday, September 13, 2012 2:24 PM
> To: Villmow, Micah
> Cc: Mon Ping Wang; llvmdev at cs.uiuc.edu Mailing List
> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between
> address spaces
> 
> 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.
[Villmow, Micah] Would we really need to add pointer specific versions for
these? Or could we as an alternative allow sext/zext/trunc to work on pointer
types?
> 
> Why is it so bad to use ptrtoint/inttoptr with some large-enough
> integer size?  Neither solution avoids exposing target information into
> IR.
> 
> -Chris

On Sep 13, 2012, at 2:23 PM, Chris Lattner <clattner at apple.com> wrote:
> 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.
> 
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.

  -- Mon Ping

On Thu, 13 Sep 2012 15:53:37 -0700
Mon Ping Wang <monping at apple.com> wrote:
> 
> On Sep 13, 2012, at 2:23 PM, Chris Lattner <clattner at apple.com>
wrote:
> 
> > 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.
> > 
> 
> 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?
If we do it this way, then I'd recommend putting the required integer
size in the TargetData string. Having alternate address spaces with a
pointer size > 64b might certainly be useful for implementing
distributed shared memory, for example.

 -Hal
>  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.
> 
>   -- Mon Ping
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

On Sep 13, 2012, at 2:26 PM, "Villmow, Micah" <Micah.Villmow at
amd.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.
> [Villmow, Micah] Would we really need to add pointer specific versions for
these?
Yes.
> Or could we as an alternative allow sext/zext/trunc to work on pointer
types?
No.

-Chris

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 9/13/2012 11:04 PM, kpneal at pobox.com wrote:
>
> On the z/Architecture [...]
Also, pointers on AS/400 are 16-bytes long (i.e. 128 bits), if I recall 
correctly.

-K

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation