[LLVMdev] Address space extension

[Pete Cooper]

On Aug 7, 2013, at 6:16 PM, Pete Cooper <peter_cooper at apple.com> wrote:

> 
> On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote:
> 
>> On 08/08/2013 02:02 AM, Justin Holewinski wrote:
>>> This worries me a bit.  This would introduce language-specific
>>> processing into SelectionDAG.  OpenCL maps address spaces one way, other
>>> languages map them in other ways.  Currently, it is the job of the
>>> front-end to map pointers into the correct address space for the target
>>> (hence the address space map in clang).  With (my understanding of) this
>>> proposal, there would be a pre-defined set of language-specific address
>>> spaces that the target would need to know about. IMO it should be the
>>> job of the front-end to do this mapping.
>> 
>> The begin of the discussion was about possible way to represent high level address space information in the IR different from target address spaces (to have the information orthogonally respect the mapping so to handle also those targets that have the trivial mapping).
>> 
>> My interpretation of the solution proposed by Pete is that the frontend emits metadata that describe address spaces (overlapping information and mapping target specific). The instruction selection simply applis the mapping encoded in the metadata. So there is no pre-defined set, but there is only a mapping algorithm implemented in the instruction selection phase "table driven", the table is encoded as metadata.
> I think its fair to have this be dealt with by targets instead of the front-end.  That way the optimizer can remain generic and use only the metadata.  CPU targets will just map every address space to 0 as they have only a single physical memory space.  GPU targets such as PTX and R600 can map to the actual HW spaces they want.
> 
> This way you have the target specific information in the backend where I believe it should be, and the front-end can target agnostic (note, I know, its not really agnostic and already contains target specific information, but I just don’t want to add more unless its really needed)
> 
> On the casting between address spaces topic "you can cast between the generic address space and global/local/private, so there's also that to consider.”.  This terrifies me.  I don’t know how to generate code for this on a system which has disjoint physical memory without branching on every memory access to that address space.
Thinking about this more…  

If you do implement something like alias analysis for address spaces, then casting between address spaces will be unsafe.

Lets say we have 3 address spaces: local, global, all.  Local and global are disjoint, all is the union of the two.

If you cast local to all, or global to all, then alias analysis will be ok as an ‘all’ pointer already aliased local or global.  However, if you cast local to all to global, then you now don’t know if other local pointers alias that so called global pointer or not.  This is analogous to casting int* to float* in C++.  Its undefined behavior according to the spec, and the compiler will optimize it as such.

Personally i’d treat it as undefined behavior and implement your code as such, but i’m no CL/CUDA expert so others may disagree.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> 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 HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130807/ec376c91/attachment.html>