[OpenCL] __generic address space for CL2.0

[Sahasrabuddhe, Sameer]

Hello Anastasia,

I am okay with the interpretation that address space qualifiers are type attributes. Thanks for following up on that! It still feels a bit weird to me that where an object lives is somehow a property of its type. But as far as I can see, that is exactly how Clang already treats them, anyway! And I suppose most (all?) OpenCL implementations out there make the same interpretation.

Sameer.
________________________________________
From: Anastasia Stulova [anastasia.stulova at arm.com]
Sent: Wednesday, November 19, 2014 5:54 PM
To: Sahasrabuddhe, Sameer; Aaron Ballman
Cc: llvm cfe
Subject: RE: [OpenCL] __generic address space for CL2.0

Hi Sameer, Aaron,

Here is my attempt to improve the documentation for the OpenCL address space attributes.

@Sameer, we had a discussion with Aaron on IRC and we believe address spaces are type attributes. We have concluded it looking at overloading-like behaviour in OpenCL BIFs. In CL v <2.0 Spec, we have such BIFs as for example 'sincos' with several overloads specified - each differs only by address space of an argument (second argument in this case) . Therefore, by changing the address space attribute of a parameter type we obtain a different function overload (which usually happens if an argument type changes). Based on this fact, we believe that changing address space actually creates a different type. Does that sound reasonable to you? If yes, we could try to request an update to Khronos Spec.

Kind Regards,
Anastasia

-----Original Message-----
From: Sahasrabuddhe, Sameer [mailto:sameer.sahasrabuddhe at amd.com]
Sent: 18 November 2014 04:39
To: Aaron Ballman; Anastasia Stulova
Cc: llvm cfe
Subject: Re: [OpenCL] __generic address space for CL2.0

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.