[cfe-dev] [LLVMdev] RFC: Representation of OpenCL Memory Spaces

[Peter Collingbourne]

On Thu, Oct 13, 2011 at 06:59:47PM +0000, Villmow, Micah wrote:
> Justin,  
>  Out of these options, I would take the metadata approach for AA support. 
> 
> This doesn't solve the problem of different frontend/backends choosing different
> address space representations for the same language, but is the correct 
> approach for providing extra information to the optimizations.
> 
> The issue about memory spaces in general is a little different. For example, based on
> the code you posted below, address space 0(default) is global in CUDA, but
> in OpenCL, the default address space is private. So, how does the ptx backend 
> handle the differences? I think this is problematic as address spaces 
> are language constructs and hardcoded at the frontend, but the backend needs to be 
> able to interpret them differently based on the source language.
> 
> One way this could be done is to have the backends have options, but then
> each backend would need to implement this. I think a better approach is 
> to have some way to represent address spaces generically in the module.

Address space 0 (i.e. the default address space) should always be the
address space on which the stack resides.  This is a requirement for
alloca to work correctly.  So for PTX, I think that address space 0
should be the local state space (but I noticed that at the moment it
is the global state space, which seems wrong IMHO).

As I mentioned in my previous email, I don't think that the backend
should interpret address spaces for the source language, as this
places too much language-specific functionality in the backend.

The situation regarding default address spaces in CUDA is more
complex, but suffice it to say that there is usually no such thing
as a "default" address space in CUDA, because the language does not
contain support for address space qualified pointer types (only address
space qualified declarations).  NVIDIA's CUDA compiler, nvopencc,
determines the correct address space for each pointer using type
inference (there is an explanation of nvopencc's algorithm in the
src/doc/ssa_memory_space.txt file in the nvopencc distribution).
Our compiler should eventually contain a similar algorithm.

Thanks,
-- 
Peter