[Clang] Make generic aliases to OpenCL address spaces

[jhuber6]

Summary

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_.

[yaxunl]

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".

clang/include/clang/Basic/Attr.td

1349

typo

[jhuber6]

Fix typo

[arsenm]

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

[jhuber6]

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.

[yaxunl]

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".

[jhuber6]

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.

[Anastasia]

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.

[arsenm]

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

[jhuber6]

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.

[jdoerfert]

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.

[jhuber6]

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.

[Anastasia]

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.

[arsenm]

Probably should just wrap uses in macros for now

[jhuber6]

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.

clang/include/clang/Basic/Attr.td

let Accessors = [Accessor<"isReadOnly", [CustomKeyword<"__read_only">,
                                             CustomKeyword<"read_write">]>,
                    Accessor<"isWriteOnly", [CustomKeyword<"__write_only">,
                                             CustomKeyword<"write_only">]>];
   let Documentation = [OpenCLAccessDocs];
 }
 
 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];
 }
 
 def OpenCLGlobalDeviceAddressSpace : TypeAttr {
   let Spellings = [Clang<"opencl_global_device">];
   let Documentation = [OpenCLAddressSpaceGlobalExtDocs];
 }
 
 def OpenCLGlobalHostAddressSpace : TypeAttr {
   let Spellings = [Clang<"opencl_global_host">];
   let Documentation = [OpenCLAddressSpaceGlobalExtDocs];
 }
 
 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];
 }
 
 def OpenCLNoSVM : Attr {
   let Spellings = [GNU<"nosvm">];
   let Subjects = SubjectList<[Var]>;
   let Documentation = [OpenCLNoSVMDocs];
   let LangOpts = [OpenCL];

clang/include/clang/Basic/AttrDocs.td

.. code-block:: c
     }
 
 More details can be found in the OpenCL C language Spec v2.0, Section 6.5.
   }];
 }
 
 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
 function parameters in non-kernel functions can have the generic address space
 type attribute. It is intended to be a placeholder for any other address space
 except for '__constant' in OpenCL code which can be used with multiple address
 spaces.
   }];
 }
 
 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.
 Any type can be annotated with the constant address space attribute. Objects
 with the constant address space qualifier can be declared in any scope and must
 have an initializer.
   }];
 }
 
 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
 memory area persists between kernel executions. Pointer types to the global
 address space are allowed as function parameters or local variables. Starting
 with OpenCL v2.0, the global address space can be used with global (program
 scope) variables and static local variable as well.
   }];

 ``global_device`` and ``global_host`` address spaces to
 ``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
 "Address space nesting and rules for pointers").
   }];
 }
 
 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
 group. The content stored in this memory region is not accessible after
 the kernel execution ends. In a kernel function scope, any variable can be in
 the local address space. In other scopes, only pointer types to the local address
 space are allowed. Local address space variables cannot have an initializer.
   }];
 }
 
 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
 content is destroyed after work item execution ends. Local variables can be
 declared in the private address space. Function arguments are always in the
 private address space. Kernel function arguments of a pointer or an array type
 cannot point to the private address space.
   }];