[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.
Herald added a subscriber: Naghasan.

In D107769#3064171 <https://reviews.llvm.org/D107769#3064171>, @svenvh wrote:

> In D107769#2967565 <https://reviews.llvm.org/D107769#2967565>, @Anastasia wrote:
>
>> In D107769#2960441 <https://reviews.llvm.org/D107769#2960441>, @svenvh wrote:
>>
>>> I have done an alternative spin of this patch: instead of introducing `RequireDisabledExtension`, simply always make the `private`, `global`, and `local` overloads available.  This makes tablegen diverge from `opencl-c.h` though.  Perhaps we should also always add make the `private`, `global`, and `local` overloads available in `opencl-c.h`?
>>
>> Yes, we could do this indeed as a clang extension. I don't think this will impact the user code. However, this means vendors will have to add definitions for extra overloads in OpenCL 2.0 mode?
>
> I wonder if making the `private`, `global`, and `local` overloads always available would even be considered an extension.  Unless I overlooked something, I cannot find anything in the spec saying that the `private`, `global`, and `local` overloads should **not** be available when a `generic` overload is available (even though this is what Clang has always done)?
>
> Making all overloads always available in e.g. CL2.0 mode will indeed affect the generated calls, which means the definitions should be available when consuming the generated IR.

The way I understand the spec for OpenCL C 2.0 is that whenever the address space of the pointer is not listed it means generic has to be used, here is one example:
https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html#vector-data-load-and-store-functions

  gentypen vloadn(size_t offset, const gentype *p)
  gentypen vloadn(size_t offset, const __constant gentype *p)

that has no address space (i.e. `generic`) and `constant` explicitly. So I think if address spaces are not listed explicitly they are not supposed to be available.

One implication of adding all address space overloads is that it makes library size larger, but my feeling is that we don't have that many functions with pointers to significantly impace the library size?


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

https://reviews.llvm.org/D107769