[LLVMdev] [cfe-dev] RFC: Representation of OpenCL Memory Spaces
justin.holewinski at gmail.com
Fri Oct 14 17:58:35 PDT 2011
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
> > > 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
> > > >
> > > > This doesn't solve the problem of different frontend/backends
> > > different
> > > > address space representations for the same language, but is the
> > > > 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
> > > 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
> > > 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
> > > > each backend would need to implement this. I think a better approach
> > > > to have some way to represent address spaces generically in the
> > >
> > > 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
> > with the back-end, address space 0 was already defined as global, and I
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev