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

[Justin Holewinski]

On Thu, Oct 13, 2011 at 4:16 PM, Peter Collingbourne <peter at pcc.me.uk>wrote:

> 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).
>

This is a bit hacky in the back-end at the moment.  When I started working
with the back-end, address space 0 was already defined as global, and I have
not broken that convention yet.

Then again, the issue is not really that big of a deal, since we need to
specially handle all "stack" accesses anyway.  It doesn't really matter much
what address space is used.


>
> 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
>



-- 

Thanks,

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