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

[Villmow, Micah]

> -----Original Message-----
> From: Peter Collingbourne [mailto:peter at pcc.me.uk]
> Sent: Friday, October 14, 2011 9:55 AM
> To: Justin Holewinski
> Cc: Villmow, Micah; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [cfe-dev] RFC: Representation of OpenCL Memory
> Spaces
> 
> On Thu, Oct 13, 2011 at 04:21:23PM -0400, Justin Holewinski wrote:
> > 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.
> 
> What kind of special handling would be required?  And how can you
> always tell whether or not an access through address space 0 would be a
> stack access?  For example, consider the attached .ll file, which
> compiles to a global store here.
[Villmow, Micah] If this was generated from OpenCL, then it is an invalid program as the default address space is private to the thread and you cannot have global variables in the private address space.
> 
> Thanks,
> --
> Peter