[OpenCL] Simplification in extensions

In this RFC I would like to discuss simplifications in the OpenCL extension
implementation, that can affect existing code. Please, provide your feedback
and concerns if any to reduce the possibility of a negative impact.

  1. Removal/prevention from adding unused extensions. Currently, about 1/3 of
    extensions added to clang are unused - extensions that are added into the
    OpenCLOptions data structure
    (https://clang.llvm.org/doxygen/OpenCLOptions_8h_source.html) but never
    appear to be used in the rest of the source code except for setting them in the
    targets. Note that some of the extensions that are added to clang don’t even have
    corresponding kernel language changes and therefore it is very unclear why
    they were added to clang in the first place (see cl_khr_spir, cl_khr_icd,
    cl_khr_context_abort, etc). There are also other 1/3 that are added for the
    sake of defining macros, however, I am wondering if more dedicated approaches
    to defining macros could be used i.e. using clang::MacroBuilder for adding macros
    directly or using headers/pre-processor command-line options.

Below I provide the list summarizing the current status of the extension uses.
As a first step, I would like to remove unused extensions described in the list III.
As a second step, I would like to find an alternative way to add extension macro
for the extensions that only add functionality in the header - list II (i.e. those
that do not affect the parser in any way), so that they can be moved out of clang
and live in headers or in pre-processor command-line options i.e. -D. I, therefore,
suggest that we create a mechanism for adding the macro corresponding to the
extensions: either by adding a target hook for loading a vendor header that
could contain a definition of those macros or a hook for adding the pre-
processor options to define those macros.

  1. Removal/prevention from adding the redundant extension pragma. Currently,
    every extension registered in clang via OpenCLOptions will add an extension
    pragma too. However, in the majority of cases, the pragma seems to be unused or
    used without adding any value leading to the increase of the complexity in
    applications and tools - one example is guarding the use of types or even
    functions by the pragma (see detailed explanation in
    Currently only cl_khr_fp64 seems to require pragma genuinely for switching the
    floating-point literal between single and double precision. I would like to
    remove such pragmas together with unused pragmas. Note that removal of old
    pragmas doesn’t necessarily break backward compatibility as the use of unknown
    pragmas is ignored with a warning. And only in cases where warnings are
    undesirable the application code is to be updated.

Both 1 and 2 have two actions: (a) refactoring of existing code and (b)
establishing clear guidelines for future development in particular OpenCL 3.0.
So even if we won’t be able to achieve all the refactoring described above, I
would at least like to set the directions for the future development that will
keep our codebase cleaner and more maintainable.

As a first step, I would like to remove unused extensions described in the list III.

To make progress on this RFC, the removal of unused extensions is covered by https://reviews.llvm.org/D89372. Any additional feedback is welcome.

Thank you,


I have uploaded the prototype patches to continue refactoring the extensions. In this phase, I would like to address the extensions from list II which are implemented as regular libraries without any changes in the parsing of the language. The summary of the refactoring are as follow:

  • Provide dedicated mechanisms for adding predefined macros for extensions, that can be added in the TargetInfo or the implicit OpenCL headers: https://reviews.llvm.org/D91531.
  • The pragma for such extensions has no functionality but to allow compiling existing kernels without the warning the pragma will not be removed but moved to a new category. A new warning is proposed for such a category that is TURNED OFF by default: https://reviews.llvm.org/D91534.
  • Make the Tablegen header (enabled by -fdeclare-opencl-builtins) work uniformly with extensions enabled via frontend and via implicit headers https://reviews.llvm.org/D91538.

Looking forward to any feedback.