[OpenCL] __generic address space for CL2.0

Anastasia Stulova anastasia.stulova at arm.com
Mon Nov 17 10:23:06 PST 2014

Thanks for these suggestions! An update is attached here.


-----Original Message-----
From: Sahasrabuddhe, Sameer [mailto:sameer.sahasrabuddhe at amd.com] 
Sent: 17 November 2014 04:38
To: Pekka Jääskeläinen; Anastasia Stulova; cfe-commits at cs.uiuc.edu
Subject: Re: [OpenCL] __generic address space for CL2.0

On 11/14/2014 3:41 PM, Pekka Jääskeläinen wrote:
> On 11/14/2014 12:01 PM, Anastasia Stulova wrote:
>> One solution to that would be to add __generic to the end of the 
>> address space enum list, but then we will have OpenCL items 
>> fragmented. I am not sure it's good.
> Yep, I don't believe it's important to retain the API compatibility in 
> this particular spot if everything else is freely changed.
I agree too. The Khronos SPIR generator has a similar patch, and seems like
the standard thing to do.

Just one question: why not directly use the appropriate number for each
target, instead of defaulting it to global? The provisional SPIR 2.0 spec
specifies "4" as the generic address space, which is a reasonable value to
use ... maybe we can use that right away. SPIR is not a "real" 
target anyway, so there's no issue of breaking anything.

For other targets, we could use zero, which seems to mean "undefined address
space, replaced with default". At least that's what the TCE and SPIR target
do for CUDA address spaces! Then it is up to each target to specify the
appropriate value when the OpenCL generic address space gets supported on
that target.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: generic_keyword_v2.patch
Type: application/octet-stream
Size: 16992 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141117/f8a77e56/attachment.obj>

More information about the cfe-commits mailing list