[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