[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D156816#4574190 , @arsenm wrote:

> Probably should just wrap uses in macros for now

In clang? Or just have users deal with `opencl_` on everything and rename it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Matt Arsenault via Phabricator via cfe-commits]

arsenm requested changes to this revision.
arsenm added a comment.
This revision now requires changes to proceed.

Probably should just wrap uses in macros for now


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

> We also are tied to OpenCL semantic of future versions.

This is what I would like to avoid aliasing to OpenCL and then starting to 
change it in a way that is not conforming or documented. Maybe there is a need 
for something like an address space for the group of related languages or 
something like that and also a way to derive and specialise from the class 
instead of forking and copying/pasting.

There were a number of proposals for similar things in the past including 
improvement to the target specific address spaces 
https://reviews.llvm.org/D62574.

If what we currently have is not good enough for all purposes perhaps it would 
make sense to start an RFC describing the problems and the requirements and 
then working out the solution that works for all the use cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D156816#4551500 , @jdoerfert wrote:

> Macros seems to be good enough. If we really need clang attributes, we need 
> new docs, and naming convention etc.

Yeah an alternative would be a new set of attributes, then we make the old ones 
OpenCL language specific. One problem is that this will probably be copy 
pasting everything a second time with no difference, but it might be fine. This 
is just the easy version. Also `addrspace_` probably isn't the best name since 
there's other non-GPU targets that use address spaces. I just think that this 
GPU generic stuff should be moved out of OpenCL in whatever way is most 
convenient.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D156816#4551417 , @jhuber6 wrote:

> In D156816#4551409 , @Anastasia 
> wrote:
>
>> Why not to just use target address space and define it to some macro with 
>> desirable spelling?
>>
>> I don't think renaming OpenCL address space to something else makes sense. 
>> It might make more sense to just introduced different model of address 
>> spaces completely. But if you use OpenCL ones then it makes sense to have 
>> adequate naming so its documentation and etc can be located.
>
> My issue is that these address spaces aren't really OpenCL specific, they 
> describe a larger concept than the OpenCL language itself and we'd like to 
> use that without needing to invoke the `opencl` name, since it's unrelated in 
> this context.



1. AS is not language or backend specific. We have mostly converged and we want 
to have some neutral spelling for the common ones.
2. This is not helping. Now the OpenCL attributes have a second spelling, but 
they are still OpenCL attributes (for the user due to the docs and for the 
developer in clang). We also are tied to OpenCL semantic of future versions.

> Why not to just use target address space and define it to some macro with 
> desirable spelling?

Macros seems to be good enough. If we really need clang attributes, we need new 
docs, and naming convention etc.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D156816#4551409 , @Anastasia wrote:

> Why not to just use target address space and define it to some macro with 
> desirable spelling?
>
> I don't think renaming OpenCL address space to something else makes sense. It 
> might make more sense to just introduced different model of address spaces 
> completely. But if you use OpenCL ones then it makes sense to have adequate 
> naming so its documentation and etc can be located.

My issue is that these address spaces aren't really OpenCL specific, they 
describe a larger concept than the OpenCL language itself and we'd like to use 
that without needing to invoke the `opencl` name, since it's unrelated in this 
context.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D156816#4551409 , @Anastasia wrote:

> Why not to just use target address space and define it to some macro with 
> desirable spelling?

If you mean the numbered address spaces, that's the broken thing this is 
specifically trying to disallow. We probably shouldn't even allow you to use 
those numbers. The numbered versions are not treated equivalently, and don't 
have the same enforced semantic rules. For example __constant__ disallows 
storing to it, but address_space(4) does. The lack of casting rules is also an 
issue


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D156816#4551357 , @jhuber6 wrote:

> In D156816#4551338 , @yaxunl wrote:
>
>>> FFI isn't the reason you'd use these, it's for generic access to the actual 
>>> backend. E.g. an `addrspace(3)` global is local memory, if it's external 
>>> it's dynamic. Having these named is better than doing it via the numerical 
>>> address space. I'd like to use these in the C++ / OpenMP codes instead of 
>>> the numeric ones but I don't like needing to use `opencl` in the name. 
>>> Similarly to how we have the OpenCL atomics that should be usable outside 
>>> of OpenCL.
>>
>> I agree these attributes are useful in other languages, but "global" and 
>> "local" may need a more generic name suitable for all offloading languages. 
>> To me, "device" can be a good alternative to "global". even "shared" seems 
>> clearer than "local".
>
> Global is common in https://llvm.org/docs/AMDGPUUsage.html#address-spaces and 
> https://llvm.org/docs/NVPTXUsage.html#address-spaces. The main problem is 
> `local` vs `shared` and `private` vs `local`. Unsure which one we should 
> prefer in this case. Generally I feel a lot of this OpenCL stuff should've 
> been named commonly at the start considering you can use most of them outside 
> of the actual OpenCL language just fine.

Why not to just use target address space and define it to some macro with 
desirable spelling?

I don't think renaming OpenCL address space to something else makes sense. It 
might make more sense to just introduced different model of address spaces 
completely. But if you use OpenCL ones then it makes sense to have adequate 
naming so its documentation and etc can be located.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D156816#4551338 , @yaxunl wrote:

>> FFI isn't the reason you'd use these, it's for generic access to the actual 
>> backend. E.g. an `addrspace(3)` global is local memory, if it's external 
>> it's dynamic. Having these named is better than doing it via the numerical 
>> address space. I'd like to use these in the C++ / OpenMP codes instead of 
>> the numeric ones but I don't like needing to use `opencl` in the name. 
>> Similarly to how we have the OpenCL atomics that should be usable outside of 
>> OpenCL.
>
> I agree these attributes are useful in other languages, but "global" and 
> "local" may need a more generic name suitable for all offloading languages. 
> To me, "device" can be a good alternative to "global". even "shared" seems 
> clearer than "local".

Global is common in https://llvm.org/docs/AMDGPUUsage.html#address-spaces and 
https://llvm.org/docs/NVPTXUsage.html#address-spaces. The main problem is 
`local` vs `shared` and `private` vs `local`. Unsure which one we should prefer 
in this case. Generally I feel a lot of this OpenCL stuff should've been named 
commonly at the start considering you can use most of them outside of the 
actual OpenCL language just fine.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D156816#4551307 , @jhuber6 wrote:

> In D156816#4551299 , @arsenm wrote:
>
>> I don't really see the point of doing this. These introduce ambiguous 
>> terminology. The reason you need the attributes is basically for FFI to 
>> opencl code, so might as well make the specific meaning clearer with the 
>> opencl bit
>
> FFI isn't the reason you'd use these, it's for generic access to the actual 
> backend. E.g. an `addrspace(3)` global is local memory, if it's external it's 
> dynamic. Having these named is better than doing it via the numerical address 
> space. I'd like to use these in the C++ / OpenMP codes instead of the numeric 
> ones but I don't like needing to use `opencl` in the name. Similarly to how 
> we have the OpenCL atomics that should be usable outside of OpenCL.

I agree these attributes are useful in other languages, but "global" and 
"local" may need a more generic name suitable for all offloading languages. To 
me, "device" can be a good alternative to "global". even "shared" seems clearer 
than "local".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added a comment.

In D156816#4551299 , @arsenm wrote:

> I don't really see the point of doing this. These introduce ambiguous 
> terminology. The reason you need the attributes is basically for FFI to 
> opencl code, so might as well make the specific meaning clearer with the 
> opencl bit

FFI isn't the reason you'd use these, it's for generic access to the actual 
backend. E.g. an `addrspace(3)` global is local memory, if it's external it's 
dynamic. Having these named is better than doing it via the numerical address 
space. I'd like to use these in the C++ / OpenMP codes instead of the numeric 
error codes but I don't like needing to use `opencl` in the name. Similarly to 
how we have the OpenCL atomics that should be usable outside of OpenCL.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

I don't really see the point of doing this. These introduce ambiguous 
terminology. The reason you need the attributes is basically for FFI to opencl 
code, so might as well make the specific meaning clearer with the opencl bit


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 546149.
jhuber6 added a comment.

Fix typo


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -3818,7 +3818,7 @@
 
 def OpenCLAddressSpaceGenericDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__generic, generic, [[clang::opencl_generic]]";
+  let Heading = "__generic, generic, [[clang::addrspace_generic]], 
[[clang::opencl_generic]]";
   let Content = [{
 The generic address space attribute is only available with OpenCL v2.0 and 
later.
 It can be used with pointer types. Variables in global and local scope and
@@ -3831,7 +3831,7 @@
 
 def OpenCLAddressSpaceConstantDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__constant, constant, [[clang::opencl_constant]]";
+  let Heading = "__constant, constant, [[clang::addrspace_constant]], 
[[clang::opencl_constant]]";
   let Content = [{
 The constant address space attribute signals that an object is located in
 a constant (non-modifiable) memory region. It is available to all work items.
@@ -3843,7 +3843,7 @@
 
 def OpenCLAddressSpaceGlobalDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__global, global, [[clang::opencl_global]]";
+  let Heading = "__global, global, [[clang::addrspace_global]], 
[[clang::opencl_global]]";
   let Content = [{
 The global address space attribute specifies that an object is allocated in
 global memory, which is accessible by all work items. The content stored in 
this
@@ -3881,7 +3881,7 @@
 
 def OpenCLAddressSpaceLocalDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__local, local, [[clang::opencl_local]]";
+  let Heading = "__local, local, [[clang::addrspace_local]], 
[[clang::opencl_local]]";
   let Content = [{
 The local address space specifies that an object is allocated in the local 
(work
 group) memory area, which is accessible to all work items in the same work
@@ -3894,7 +3894,7 @@
 
 def OpenCLAddressSpacePrivateDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__private, private, [[clang::opencl_private]]";
+  let Heading = "__private, private, [[clang::addrspace_private]], 
[[clang::opencl_private]]";
   let Content = [{
 The private address space specifies that an object is allocated in the private
 (work item) memory. Other work items cannot access the same memory area and its
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -1344,13 +1344,13 @@
 
 def OpenCLPrivateAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__private">, CustomKeyword<"private">,
-   Clang<"opencl_private">];
+   Clang<"opencl_private">, Clang<"addrspace_private">];
   let Documentation = [OpenCLAddressSpacePrivateDocs];
 }
 
 def OpenCLGlobalAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__global">, CustomKeyword<"global">,
-   Clang<"opencl_global">];
+   Clang<"opencl_global">, Clang<"addrspace_global">];
   let Documentation = [OpenCLAddressSpaceGlobalDocs];
 }
 
@@ -1366,19 +1366,19 @@
 
 def OpenCLLocalAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__local">, CustomKeyword<"local">,
-   Clang<"opencl_local">];
+   Clang<"opencl_local", Clang<"addrspace_local">>];
   let Documentation = [OpenCLAddressSpaceLocalDocs];
 }
 
 def OpenCLConstantAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__constant">, CustomKeyword<"constant">,
-   Clang<"opencl_constant">];
+   Clang<"opencl_constant", Clang<"addrspace_constant">>];
   let Documentation = [OpenCLAddressSpaceConstantDocs];
 }
 
 def OpenCLGenericAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__generic">, CustomKeyword<"generic">,
-   Clang<"opencl_generic">];
+   Clang<"opencl_generic", Clang<"addrspace_generic">>];
   let Documentation = [OpenCLAddressSpaceGenericDocs];
 }
 


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -3818,7 +3818,7 @@
 
 def OpenCLAddressSpaceGenericDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__generic, generic, [[clang::opencl_generic]]";
+  let Heading = "__generic, generic, [[clang::addrspace_generic]], [[clang::opencl_generic]]";
   let C

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

Are these attributes supposed to be used in other languages? Some of their 
names are meaningful only in OpenCL and could be confusing/ambiguous for other 
languages, e.g "global" and "local".




Comment at: clang/include/clang/Basic/Attr.td:1348
+   Clang<"opencl_private">, Clang<"addrspace_private">];
+  let Documentation = [kpenCLAddressSpacePrivateDocs];
 }

typo


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156816/new/

https://reviews.llvm.org/D156816

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D156816: [Clang] Make generic aliases to OpenCL address spaces

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: ebevhan, arsenm, JonChesterfield, jdoerfert, 
tianshilei1992, tra, yaxunl, rjmccall.
Herald added subscribers: jeroen.dobbelaere, Naghasan, ldrumm, arichardson, 
Anastasia.
Herald added a reviewer: aaron.ballman.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, wangpc, wdng.
Herald added a project: clang.

We provide these OpenCL attributes for specifying address spaces. These
more or less map directly to the versions described by the backend
documentation. However, when using these for more generic reasons, the
`opencl` keyword doesn't help since this is more tied to the backend.
This patch adds an alias to just call it `addrspace_` instead of
`opencl_`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D156816

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -3818,7 +3818,7 @@
 
 def OpenCLAddressSpaceGenericDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__generic, generic, [[clang::opencl_generic]]";
+  let Heading = "__generic, generic, [[clang::addrspace_generic]], 
[[clang::opencl_generic]]";
   let Content = [{
 The generic address space attribute is only available with OpenCL v2.0 and 
later.
 It can be used with pointer types. Variables in global and local scope and
@@ -3831,7 +3831,7 @@
 
 def OpenCLAddressSpaceConstantDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__constant, constant, [[clang::opencl_constant]]";
+  let Heading = "__constant, constant, [[clang::addrspace_constant]], 
[[clang::opencl_constant]]";
   let Content = [{
 The constant address space attribute signals that an object is located in
 a constant (non-modifiable) memory region. It is available to all work items.
@@ -3843,7 +3843,7 @@
 
 def OpenCLAddressSpaceGlobalDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__global, global, [[clang::opencl_global]]";
+  let Heading = "__global, global, [[clang::addrspace_global]], 
[[clang::opencl_global]]";
   let Content = [{
 The global address space attribute specifies that an object is allocated in
 global memory, which is accessible by all work items. The content stored in 
this
@@ -3881,7 +3881,7 @@
 
 def OpenCLAddressSpaceLocalDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__local, local, [[clang::opencl_local]]";
+  let Heading = "__local, local, [[clang::addrspace_local]], 
[[clang::opencl_local]]";
   let Content = [{
 The local address space specifies that an object is allocated in the local 
(work
 group) memory area, which is accessible to all work items in the same work
@@ -3894,7 +3894,7 @@
 
 def OpenCLAddressSpacePrivateDocs : Documentation {
   let Category = DocOpenCLAddressSpaces;
-  let Heading = "__private, private, [[clang::opencl_private]]";
+  let Heading = "__private, private, [[clang::addrspace_private]], 
[[clang::opencl_private]]";
   let Content = [{
 The private address space specifies that an object is allocated in the private
 (work item) memory. Other work items cannot access the same memory area and its
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -1344,13 +1344,13 @@
 
 def OpenCLPrivateAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__private">, CustomKeyword<"private">,
-   Clang<"opencl_private">];
-  let Documentation = [OpenCLAddressSpacePrivateDocs];
+   Clang<"opencl_private">, Clang<"addrspace_private">];
+  let Documentation = [kpenCLAddressSpacePrivateDocs];
 }
 
 def OpenCLGlobalAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__global">, CustomKeyword<"global">,
-   Clang<"opencl_global">];
+   Clang<"opencl_global">, Clang<"addrspace_global">];
   let Documentation = [OpenCLAddressSpaceGlobalDocs];
 }
 
@@ -1366,19 +1366,19 @@
 
 def OpenCLLocalAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__local">, CustomKeyword<"local">,
-   Clang<"opencl_local">];
+   Clang<"opencl_local", Clang<"addrspace_local">>];
   let Documentation = [OpenCLAddressSpaceLocalDocs];
 }
 
 def OpenCLConstantAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__constant">, CustomKeyword<"constant">,
-   Clang<"opencl_constant">];
+   Clang<"opencl_constant", Clang<"addrspace_constant">>];
   let Documentation = [OpenCLAddressSpaceConstantDocs];
 }
 
 def OpenCLGenericAddressSpace : TypeAttr {
   let Spellings = [CustomKeyword<"__generic">, Custo