Skip to content

Conversation

@vmustya
Copy link
Contributor

@vmustya vmustya commented Mar 4, 2025

This patch adds handling for the following OpenCL extensions, passed as
-cl-ext arguments to Clang:

  • cl_khr_extended_bit_ops
  • cl_khr_integer_dot_product
  • cl_khr_subgroup_ballot
  • cl_khr_subgroup_clustered_reduce
  • cl_khr_subgroup_extended_types
  • cl_khr_subgroup_named_barrier
  • cl_khr_subgroup_non_uniform_arithmetic
  • cl_khr_subgroup_non_uniform_vote
  • cl_khr_subgroup_rotate
  • cl_khr_subgroup_shuffle
  • cl_khr_subgroup_shuffle_relative
  • cl_khr_work_group_uniform_arithmetic
  • cl_intel_subgroups_char
  • cl_intel_subgroups_long

This patch adds handling for the following OpenCL extensions, passed as
`-cl-ext` arguments to Clang:
- cl_khr_extended_bit_ops
- cl_khr_integer_dot_product
- cl_khr_subgroup_ballot
- cl_khr_subgroup_clustered_reduce
- cl_khr_subgroup_extended_types
- cl_khr_subgroup_named_barrier
- cl_khr_subgroup_non_uniform_arithmetic
- cl_khr_subgroup_non_uniform_vote
- cl_khr_subgroup_rotate
- cl_khr_subgroup_shuffle
- cl_khr_subgroup_shuffle_relative
- cl_khr_work_group_uniform_arithmetic
- cl_intel_subgroups_char
- cl_intel_subgroups_long
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Mar 4, 2025
@llvmbot
Copy link
Member

llvmbot commented Mar 4, 2025

@llvm/pr-subscribers-clang

Author: Victor Mustya (vmustya)

Changes

This patch adds handling for the following OpenCL extensions, passed as
-cl-ext arguments to Clang:

  • cl_khr_extended_bit_ops
  • cl_khr_integer_dot_product
  • cl_khr_subgroup_ballot
  • cl_khr_subgroup_clustered_reduce
  • cl_khr_subgroup_extended_types
  • cl_khr_subgroup_named_barrier
  • cl_khr_subgroup_non_uniform_arithmetic
  • cl_khr_subgroup_non_uniform_vote
  • cl_khr_subgroup_rotate
  • cl_khr_subgroup_shuffle
  • cl_khr_subgroup_shuffle_relative
  • cl_khr_work_group_uniform_arithmetic
  • cl_intel_subgroups_char
  • cl_intel_subgroups_long

Full diff: https://github.com/llvm/llvm-project/pull/129777.diff

2 Files Affected:

  • (modified) clang/include/clang/Basic/OpenCLExtensions.def (+21)
  • (modified) clang/lib/Basic/OpenCLOptions.cpp (+8-1)
diff --git a/clang/include/clang/Basic/OpenCLExtensions.def b/clang/include/clang/Basic/OpenCLExtensions.def
index 6f73b26137500..09ab1245a6a9a 100644
--- a/clang/include/clang/Basic/OpenCLExtensions.def
+++ b/clang/include/clang/Basic/OpenCLExtensions.def
@@ -90,13 +90,29 @@ OPENCL_EXTENSION(__cl_clang_variadic_functions, true, 100)
 OPENCL_EXTENSION(__cl_clang_non_portable_kernel_param_types, true, 100)
 OPENCL_EXTENSION(__cl_clang_bitfields, true, 100)
 
+// Khronos OpenCL extensions
+OPENCL_EXTENSION(cl_khr_extended_bit_ops, true, 100)
+OPENCL_EXTENSION(cl_khr_integer_dot_product, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_ballot, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_clustered_reduce, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_extended_types, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_named_barrier, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_non_uniform_arithmetic, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_non_uniform_vote, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_rotate, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_shuffle, true, 100)
+OPENCL_EXTENSION(cl_khr_subgroup_shuffle_relative, true, 100)
+OPENCL_EXTENSION(cl_khr_work_group_uniform_arithmetic, true, 200)
+
 // AMD OpenCL extensions
 OPENCL_EXTENSION(cl_amd_media_ops, true, 100)
 OPENCL_EXTENSION(cl_amd_media_ops2, true, 100)
 
 // Intel OpenCL extensions
 OPENCL_EXTENSION(cl_intel_subgroups, true, 120)
+OPENCL_EXTENSION(cl_intel_subgroups_char, true, 120)
 OPENCL_EXTENSION(cl_intel_subgroups_short, true, 120)
+OPENCL_EXTENSION(cl_intel_subgroups_long, true, 120)
 OPENCL_EXTENSION(cl_intel_device_side_avc_motion_estimation, true, 120)
 
 // OpenCL C 3.0 features (6.2.1. Features)
@@ -112,6 +128,11 @@ OPENCL_OPTIONALCOREFEATURE(__opencl_c_program_scope_global_variables, false, 300
 OPENCL_OPTIONALCOREFEATURE(__opencl_c_fp64, false, 300, OCL_C_30)
 OPENCL_OPTIONALCOREFEATURE(__opencl_c_images, false, 300, OCL_C_30)
 
+// Features enabled by the Khronos extensions
+OPENCL_GENERIC_EXTENSION(__opencl_c_work_group_collective_functions, false, 300, 0)
+OPENCL_GENERIC_EXTENSION(__opencl_c_integer_dot_product_input_4x8bit, false, 300, 0)
+OPENCL_GENERIC_EXTENSION(__opencl_c_integer_dot_product_input_4x8bit_packed, false, 300, 0)
+
 #undef OPENCL_OPTIONALCOREFEATURE
 #undef OPENCL_COREFEATURE
 #undef OPENCL_GENERIC_EXTENSION
diff --git a/clang/lib/Basic/OpenCLOptions.cpp b/clang/lib/Basic/OpenCLOptions.cpp
index d39686ea688e5..9a58605294873 100644
--- a/clang/lib/Basic/OpenCLOptions.cpp
+++ b/clang/lib/Basic/OpenCLOptions.cpp
@@ -18,7 +18,14 @@ static const std::pair<StringRef, StringRef> DependentFeaturesList[] = {
     {"__opencl_c_3d_image_writes", "__opencl_c_images"},
     {"__opencl_c_pipes", "__opencl_c_generic_address_space"},
     {"__opencl_c_device_enqueue", "__opencl_c_generic_address_space"},
-    {"__opencl_c_device_enqueue", "__opencl_c_program_scope_global_variables"}};
+    {"__opencl_c_device_enqueue", "__opencl_c_program_scope_global_variables"},
+    {"__opencl_c_work_group_collective_functions",
+     "cl_khr_work_group_uniform_arithmetic"},
+    {"__opencl_c_integer_dot_product_input_4x8bit",
+     "cl_khr_integer_dot_product"},
+    {"__opencl_c_integer_dot_product_input_4x8bit_packed",
+     "cl_khr_integer_dot_product"},
+};
 
 // Extensions and equivalent feature pairs.
 static const std::pair<StringRef, StringRef> FeatureExtensionMap[] = {

@bader bader requested a review from svenvh March 4, 2025 21:59
Copy link
Member

@svenvh svenvh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation for this change? We are trying to move away from adding extensions to this file for extensions that only add builtin functions, see e.g. https://reviews.llvm.org/D92231 . What functionality are you gaining by adding them here?

@vmustya
Copy link
Contributor Author

vmustya commented Mar 5, 2025

What is the motivation for this change? We are trying to move away from adding extensions to this file for extensions that only add builtin functions, see e.g. https://reviews.llvm.org/D92231 . What functionality are you gaining by adding them here?

@svenvh, I'm trying to unify the extensions enablement in the user interface. We can enable or disable some of the extensions with the -Xclang -cl-ext=+extension command line options. For example, a user can pass -Xclang -cl-ext=+cl_khr_subgroups successfully, but the -Xclang -cl-ext=+cl_khr_subgroup_ballot has no effect on the compiler.

@svenvh
Copy link
Member

svenvh commented Mar 5, 2025

@svenvh, I'm trying to unify the extensions enablement in the user interface. We can enable or disable some of the extensions with the -Xclang -cl-ext=+extension command line options. For example, a user can pass -Xclang -cl-ext=+cl_khr_subgroups successfully, but the -Xclang -cl-ext=+cl_khr_subgroup_ballot has no effect on the compiler.

Got it, thanks for looking into this!

I'm trying to refresh my memory on this, as this is something Anton, Anastasia and myself looked at back in 2021, but we never concluded the work. From the most recent discussion I could find on this topic, I think the consensus was that for header-only extensions given to -cl-ext (such as -cl-ext=+cl_khr_subgroup_ballot) clang should just define the corresponding macro (-Dcl_khr_subgroup_ballot), probably in TargetInfo::setCommandLineOpenCLOpts. That way, header-only extensions don't need to be added to OpenCLExtensions.def

@vmustya
Copy link
Contributor Author

vmustya commented Mar 5, 2025

That way, header-only extensions don't need to be added to OpenCLExtensions.def

@svenvh, in any case, we need a list of all the supported extensions, including the header ones. When someone passes the -Xclang -cl-ext=+all, the compiler should add defines for all the supported extensions.

@svenvh
Copy link
Member

svenvh commented Mar 6, 2025

When someone passes the -Xclang -cl-ext=+all, the compiler should add defines for all the supported extensions.

Indeed; we already have such a list in opencl-c-base.h to enable all header-only extensions for the spir/spirv targets, so it should be easy to make -cl-ext=+all also enable those defines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants