[OpenCL] __generic address space for CL2.0

[Anastasia Stulova]

@Sameer, I agree this bit is non-intuitive and also spec is ambiguous about
it. Still having them type attributes seems to make sense and it has been
already implemented that they. I will try to clarify this matter with
Khronos though. 

@Aaron, I attached the patch here with your last comments added.

Thanks,
Anastasia

-----Original Message-----
From: Sahasrabuddhe, Sameer [mailto:Sameer.Sahasrabuddhe at amd.com] 
Sent: 20 November 2014 17:26
To: Anastasia Stulova; Aaron Ballman
Cc: llvm cfe
Subject: RE: [OpenCL] __generic address space for CL2.0

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_keyword_v4.patch
Type: application/octet-stream
Size: 17276 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141120/12776d60/attachment.obj>