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

[Justin Holewinski]

On Fri, Oct 14, 2011 at 9:55 AM, Peter Collingbourne <peter at pcc.me.uk>wrote:

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

Yes, this is currently an issue with the back-end.  The handling of stack
space is definitely a hack at the moment, but I have not had the time to
address it since it currently works in the typical use case.


>
> Thanks,
> --
> Peter
>



-- 

Thanks,

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