[cfe-dev] Clang and OpenCL address spaces

Peter Collingbourne peter at pcc.me.uk
Tue Oct 19 11:10:56 PDT 2010


Hi John,

On Tue, Oct 19, 2010 at 10:40:20AM -0700, John McCall wrote:
> On Oct 19, 2010, at 10:15 AM, Peter Collingbourne wrote:
> > To a certain extent I agree.  But then again the storage class seems
> > to be a Clang-level implementation detail (storage classes other than
> > 'typedef' are not supported in OpenCL).  If one accesses a variable
> > outside its lifetime then that is undefined behaviour, so any lifetime
> > restrictions seem like a lower bound rather than an upper bound.
> > The spec also forbids __local variables from being initialised,
> > as well as recursion, so the semantics seem to be the same.
> > 
> > I suppose the real differences arise at the codegen level where the
> > storage class makes the difference between a global variable and
> > an 'alloca' instruction being emitted, and I don't think 'alloca'
> > supports address spaces (maybe it should?).
> 
> The call stack is always in the generic address space, so I don't know
> how 'alloca' could possibly support address spaces.

OpenCL disallows recursion and function pointers, so the call
graph would be known at compile time.  I can think of a couple of
plausible backend implementations of nonzero address space 'alloca'
under these constraints.

> I guess the $64,000 question is how you're planning on emitting these
> in IR.  If you're going to emit them as globals and then rewrite all the
> references in a later pass, then 'static' seems fine.

Globals would work for my purposes.  Hopefully Anton will be able to
chime in later regarding 'real' GPU implementations.

Thanks,
-- 
Peter



More information about the cfe-dev mailing list