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

[Villmow, Micah]

Here is the patch that i've developed that implements the below points. The test itself won't work until the target data changes are added.

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Villmow, Micah
> Sent: Friday, September 14, 2012 8:16 AM
> To: Chris Lattner; Mon Ping Wang
> Cc: llvmdev at cs.uiuc.edu Mailing List
> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between
> address spaces
> 
> 
> 
> > -----Original Message-----
> > From: Chris Lattner [mailto:clattner at apple.com]
> > Sent: Thursday, September 13, 2012 11:53 PM
> > To: Mon Ping Wang
> > Cc: Villmow, Micah; llvmdev at cs.uiuc.edu Mailing List
> > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting
> > between address spaces
> >
> >
> > 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.
> [Villmow, Micah] So basically we don't need a new IR instructions, but
> instead
> 1) bitcasts between pointers of different size is illegal, the proper
> approach is inttoptr/ptrtoint.
> 2) bitcasts between pointers of the same size stays legal.
> 3) No new IR instruction is needed, as converting between pointers of
> different sizes requires inttoptr/ptrtoint.
> 
> The only issues are then to update the verifier to assert on bitcasts
> between pointers of different sizes and add in auto-upgrade of binaries
> to switch to inttoptr/ptrtoint. By doing this, I then can clear the way
> for allowing LLVM to support multiple pointer sizes.
> 
> Sound good?
> 
> Micah
> >
> > -Chris
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bitcast_between_pointer_patch.txt
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120918/e8cd6bdd/attachment.txt>