[LLVMdev] Address space extension

[Micah Villmow]

This is something I proposed last year, so you might want to read up on that discussion first.

You can find it here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html

micah

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Michele Scandale
> Sent: Thursday, August 08, 2013 5:39 AM
> To: Justin Holewinski
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> On 08/08/2013 02:16 PM, Justin Holewinski wrote:
> > Why should SelectionDAGBuilder generate an explicit bitcast for a
> > no-op bitcast?
> 
> The bitcast operation isn't just the reinterpretation (change in the
> semantic) of the bits without any change in the value of the bits itself? If the
> size and value do not change should be fine.
> 
> > By definition, no bits are changed; so if the EVTs match, there is
> > nothing to do.  The fundamental problem is how address spaces are
> > handled, and specifically how they are converted, in LLVM IR.
> >   Address space casts are currently implemented with bitcasts (in
> > general).  While this works out for the LLVM IR type system, it does
> > not match the semantics of an address space cast for some targets.
> > For PTX, and address space cast may involve changing bits in the address.
> >   Therefore, a bitcast is not a valid way to perform an address space
> > cast.  We introduced target intrinsics to perform address space casts
> > for this purpose.  But I feel that this problem is likely not specific
> > to PTX.  A target that uses different pointer sizes for different
> > address spaces would be hit by this issue even more, since a bitcast
> > would not even be valid IR.
> 
> I agree with this, probably a 'ptrcast' instruction would better fits the various
> cases allowing the targets to handle correctly all the cases where the
> size/value change.
> 
> It seems that there are various 'little' problems in the way address spaces are
> currently handled. I think it may be useful to list the various issues in order to
> plan a common solution.
> 
> Thanks.
> 
> -Michele
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev