[cfe-dev] Clang and OpenCL address spaces

[Peter Collingbourne]

Hi Anton,

On Tue, Oct 19, 2010 at 05:39:48PM +0100, Anton Lokhmotov wrote:
> Hi Peter,
> 
> > From my understanding of the OpenCL specification, setting the address
> > space on an automatic variable is supposed to not only change the
> > address space but also make the variable static (as the term is defined
> > in standard C).  Adding 'static' to the qualifier macro definitions
> > won't work too well because the qualifiers can also appear in other
> > places.
> 
> First, I'm not sure whether 'static' is completely appropriate here:
> lifetime of __local variables is limited to lifetime of a single workgroup
> (unlike 'static' variables in C with the program's lifetime).

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

> Third, the OpenCL spec is imprecise in a number of
> points concerning address space qualifiers, which I would like to clarify
> with Khronos.  For starters, can you declare __global variables in
> functions?

Indeed.  Much of my argument here seems to be based on inferences rather
than what is actually spelt out in the spec.

Also, I'm not entirely sure, following a strict reading of the spec,
whether __constant variables are intended to be supported in functions,
as the spec seems to contradict itself.  I raised a bug report with
Khronos here:
http://www.khronos.org/bugzilla/show_bug.cgi?id=366

Thanks,
-- 
Peter