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

[Hal Finkel]

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