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

[Villmow, Micah]

> -----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