[cfe-dev] [OpenCL] Simplification in extensions

[Marco Antognini via cfe-dev]

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,
Marco
________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org>
Sent: 30 September 2020 11:24
To: clang developer list <cfe-dev at lists.llvm.org>
Cc: nd <nd at arm.com>
Subject: [cfe-dev] [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.

2. *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
https://github.com/KhronosGroup/OpenCL-Docs/pull/355#issuecomment-662679499<https:%20//github.com/KhronosGroup/OpenCL-Docs/pull/355#issuecomment-662679499>).
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.

==================================
List of the OpenCL extensions classified by their use
==================================

I. Used by the parser (and optionally in internal headers)

cl_khr_fp64
cl_khr_fp16
cl_khr_gl_msaa_sharing
cl_khr_3d_image_writes
cl_khr_subgroups
cl_khr_int64_base_atomics
cl_khr_int64_extended_atomics
cl_khr_mipmap_image
cl_khr_mipmap_image_writes
cl_intel_subgroups
cl_intel_device_side_avc_motion_estimation

II. Used in internal headers

cl_khr_depth_images
cl_khr_subgroup_extended_types
cl_khr_subgroup_non_uniform_vote
cl_khr_subgroup_ballot
cl_khr_subgroup_non_uniform_arithmetic
cl_khr_subgroup_extended_type
cl_khr_subgroup_shuffle
cl_khr_subgroup_shuffle_relative
cl_khr_subgroup_clustered_reduce
cl_khr_global_int32_base_atomics
cl_khr_global_int32_extended_atomics
cl_khr_local_int32_base_atomics
cl_khr_local_int32_extended_atomics
cl_amd_media_ops
cl_amd_media_ops2
cl_arm_integer_dot_product_int8
cl_arm_integer_dot_product_accumulate_int8
cl_arm_integer_dot_product_accumulate_int16
cl_arm_integer_dot_product_accumulate_saturate_int8

III. Unused (defined and optionally set by the targets, but not used in parser or header)

cl_khr_icd
cl_khr_initialize_memory
cl_khr_d3d10_sharing
cl_khr_gl_event
cl_khr_egl_image
cl_khr_context_abort
cl_khr_d3d11_sharing
cl_khr_dx9_media_sharing
cl_khr_image2d_from_buffer
cl_khr_gl_depth_images
cl_khr_spir
cl_khr_srgb_image_writes
cl_khr_terminate_context
cles_khr_int64
cl_intel_subgroups_short


Looking forward to any feedback!
Thank you,
Anastasia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201014/deacf3c0/attachment-0001.html>