[PATCH] D92004: [OpenCL] add CL 3.0 optional feature support to opencl-c.h

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D92004#2414692 <https://reviews.llvm.org/D92004#2414692>, @airlied wrote:

> In D92004#2413560 <https://reviews.llvm.org/D92004#2413560>, @Anastasia wrote:
>
>> Btw how about making some checks simpler. We could always define feature macros `__opencl_c_atomic_scope_device`, `__opencl_c_generic_address_space` for  OpenCL 2.0 or C++ for OpenCL . Then everywhere we would only need to check feature macros instead of language versions and feature macros together.
>>
>>   #if !(defined()) && (defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0))
>>   #define __opencl_c_atomic_scope_device      1
>>   #define __opencl_c_generic_address_space   1
>>   ...
>>   #endif
>
> I like this idea but my only worry was about leaking those definitions to the user source when the system hasn't defined them.
>
> i.e. a CL2.0 user now sees __opencl_c_generic_address_space, writes code to use that macro, but it fails on other OpenCL C implementations.
>
> But if we are going to have feature code that works like that then I'm fine with going ahead and changing things to look like this.

Identifiers that start with a double underscore are reserved so there is no real harm in defining them for earlier OpenCL C versions. FYI there is this PR https://github.com/KhronosGroup/OpenCL-Docs/pull/477 where we intend to clarify that the earlier OpenCL C version might have the macro defined too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92004