[OpenCL] __generic address space for CL2.0

[Sahasrabuddhe, Sameer]

On 11/18/2014 12:31 AM, Aaron Ballman wrote:
> +  let Content = [{
> +The address space qualifier may be used in variable declarations to specify the
> +region of memory that is used to allocate the object. OpenCL supports the
> +following address spaces: __generic/generic, __global/global, __local/local,
> +__private/private, __constant/constant
> +
> +   .. code-block:: opencl
> +
> +  __constant int c = ...;
> +
> +  __generic int* foo(global int* g) {
> +     __local int* l;
> +     private int p;
> +     ...
> +     return l;
> +  }
> +
> +  }];
> +}
> +
> I thought that these were all type attributes, not a declaration
> attributes? If so, the documentation is a bit confusing, because it
> mostly focuses on declarations instead of types.

The OpenCL seems to say that these are declaration attributes, but then 
immediately mixes things up by talking about types:

     "The address space qualifier may be used in variable
       declarations to specify the region of memory that is used to 
allocate the object. The C syntax for
       type qualifiers is extended in OpenCL to include an address space 
name as a valid type qualifier.
       If the type of an object is qualified by an address space name, 
the object is allocated in the
       specified address name; otherwise, the object is allocated in the 
generic address space."

Phrases like "a valid type qualifier" and "type of an object is 
qualified by" does create some ambiguity. But the first sentence seems 
to be designed to over-rule the rest. For example, is it okay to use an 
address space name in a typedef?

>> +(non-modifiable) memory region. It is available to all work items.
>> +Constant declarations are allowed with any type and in any scope. Such
> "Types annotated with the constant address space attribute" instead of
> "constant declarations" ?

Or perhaps "objects declared with the constant address space qualifier", 
to keep things consistent with the OpenCL spec?

>> +which is accessible by all work items. The content stored in this memory
>> +area persists between kernel executions. Variables declared in global address
>> +space are allowed as function parameters or inside a function body (and must be
>> +pointer types in both cases). Starting from OpenCL v2.0, global address space can
>> +be used with program scope variables as well.

Function parameters can only be in private address space. They may point 
to global address space if they are pointers. Non-pointer variables can 
be declared inside a function body with global address space, but they 
are required to be static.

>> +group memory area, which is accessible by all work items in the same work group.
>> +The content stored in this memory region is not accessible after the kernel
>> +execution ends. Variables declared in local address space are allowed as function
>> +parameters or inside a kernel function body.

Function parameters can point to local address space if they are 
pointers, but they can't be "in the local address space". Variables 
declared in the local address space are allowed only in kernel function 
scope. This is stricter than just "body", because they can't occur 
inside a control block. Also, such variables cannot be initialized.

>> +content is destroyed after work item execution ends. Declarations in
>> +private address space are allowed as non-kernel function parameters or inside
>> +a function body.

All function parameters are always in private address space. This is 
true even for kernels. Also this is the default address space for all 
variable declarations "inside a function" (that's the way the OpenCL 
spec says it ... does "local scope" always mean the same thing?).

Sameer.