[LLVMdev] Address space extension

[Justin Holewinski]

On Thu, Aug 8, 2013 at 12:51 PM, Pete Cooper <peter_cooper at apple.com> wrote:

>
>
> Sent from my iPhone
>
> > On Aug 8, 2013, at 5:39 AM, Michele Scandale <michele.scandale at gmail.com>
> wrote:
> >
> >> 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.
> I think the main problem is what David demonstrate earlier. That is, a
> pointer whose value and size don't change when cast to a different address
> space, but for which you must actually generate different instructions for
> in codegen.
>
>
The IR should be agnostic towards whether bits change or not.  That is
purely target-defined, and may even vary within a target.


> I think any use of addrspacecast should require metadata defining the
> address space hierarchy. Casting between overlapping regions in the
> hierarchy would be allowed. Casting between non overlapping regions would
> either be undefined or an error.
>

I like having such a guarantee available, but I hesitate to *require*
metadata in the IR.  Perhaps if the metadata doesn't exist the verifier
assumes the casts are valid and the optimizers have to assume all address
spaces alias?


>
> In the example David gave with address spaces 0 and 256. Clearly there
> isn't a single HW instruction which can use the value of the pointer to do
> the right thing at run time here. You really must generate different code.
> Therefore in the hierarchy 0 and 256 would be defined to not overlap and
> the cast would be invalid.
>
> I don't know about current GPU HW but I assume that similarly casting
> between say a local and private pointer may not be allowed as that's a very
> different thing in the backend. Anyone with more knowledge feel free to
> correct me though.
>

For PTX, casting between two non-generic pointer types is not allowed.
 Even though they are treated very similarly in the back-end, the address
bits are just not compatible.


>
> However on x86 in CL, casting between local and private is fine because
> both just generate ordinary load/store instructions. Therefore on x86 those
> regions would overlap in the memory space hierarchy.
>

Is that really what we want though?  This seems like a good use-case for
enabling better optimization on X86.  Both local and private will
ultimately be in address space 0 for the target, but you want them to be
treated as disjoint as far as the optimizers are concerned since the
programming model guarantees that there will not be aliasing between
private and local pointers.


>
> Thanks
> Pete
> >
> > Thanks.
> >
> > -Michele
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130808/96251ec5/attachment.html>