[LLVMdev] Address space extension

[Pete Cooper]

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.

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.

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.

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.

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