[cfe-dev] [RFC] OpenCL C 3.0 support in clang

[Zabaznov, Anton via cfe-dev]

Hi! I'm happy to announce OpenCL C 3.0 support in clang.

Language specification is available at https://github.com/KhronosGroup/OpenCL-Docs. OpenCL C 3.0 language standard is now backward compatible with 1.2 and makes 2.0 features optional. New OpenCL language specification is important because it allows platform vendors to optionally support OpenCL C 2.0 features which are no longer required for compliance with the core specification. This allows vendors to port OpenCL implementations on high variety of devices by choosing necessary functionality to implement. Such vendors as Intel and ARM are highly interested in OpenCL C 3.0. So I encourage everyone else who is also looking forward for OpenCL C 3.0 support in clang to take part in the following discussions and reviews.

In OpenCL 3.0 support of various features is indicated with a feature test macros. This is pretty much similar to C++ feature test macros but the difference is that the presence and the value of the latter directly relates to C++ language standard. The presence of feature test macros in OpenCL C 3.0 in the contrary is target specific: macros are being optionally defined by the frontend compiler depending on whether the target architecture supports feature or not.

------- Implementation Details -------

First it is worth mentioning that there are no big conceptual changes in clang expected since OpenCL C 3.0 makes 2.0 features optional. I've been working on OpenCL C 3.0 support in Intel and full patch is already published in Intel opencl-clang repo:

https://github.com/intel/opencl-clang/tree/ocl-open-110/patches/clang

There already exists such concept as extensions in OpenCL C language specification which has a similar meaning with OpenCL features. The difference between two of them is that OpenCL extensions are not the part of core specification and require special pragma directive to enable them. Despite the fact that features and extensions are different I tried to reuse the current extension mechanism in clang as much as possible to avoid code duplication. Also, I'm going to introduce new LangOpts flags for OpenCL C specific keywords such as 'generic' and 'pipe'; and 'OPENCLBUILTIN' concept (instead of 'LANGBUILTIN') to forward OpenCL C feature name as a parameter.

The main idea behind proposed implementation is that feature tests macros are being defined by compiler in all OpenCL versions and can't be disabled in versions prior to 3.0. This unified approach will help to avoid additional checks when identifying various types and built-ins support for all OpenCL versions in both: in clang and opencl-c.h header. Also, it logically expresses compiler behavior for other OpenCL versions, for example: OpenCL C 2.0 supports generic address space by default thus '__opencl_c_generic_address_space' macro is defined when '-cl-std=CL2.0' option is used.

There are some cases when for OpenCL C 3.0 feature already exists equivalent OpenCL C extension ('__opencl_c_3d_image_writes' and 'cl_khr_3d_image_writes'). The strategy which I decided to follow here is to provide simultaneous test macro presence for both: for feature and corresponding extension because they describe same functionality. Additionally, the reason for this is backward compatibility: there may be older applications where extension macro is checked instead of feature macro. With this approach older applications will continue to compile with OpenCL C 3.0

Please let me know if you have any concerns about this proposal, I would be glad to discuss it.
--------------------------------------

Here is a very first step on a route to upstreaming of OpenCL C 3.0 support in clang:

https://reviews.llvm.org/D88300

This initial patch adds option and predefined macros for OpenCL C 3.0 version.

Thanks in advance!
Anton.

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200925/ef0fa234/attachment.html>