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