Skip to content

[NVPTX] Support the OpenCL generic addrspace feature by default #137940

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

frasercrmck
Copy link
Contributor

As best as I can see, all NVPTX architectures support the generic address space.

I note there's a FIXME in the target's address space map about 'generic' still having to be added to the target but we haven't observed any issues with it downstream. The generic address space is mapped to the same target address space as default/private (0), but this isn't necessarily a problem for users.

As best as I can see, all NVPTX architectures support the generic
address space.

I note there's a FIXME in the target's address space map about 'generic'
still having to be added to the target but we haven't observed any
issues with it downstream. The generic address space is mapped to the
same target address space as default/private (0), but this isn't
necessarily a problem for users.
@frasercrmck frasercrmck requested a review from AlexMaclean April 30, 2025 09:16
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Apr 30, 2025
@llvmbot
Copy link
Member

llvmbot commented Apr 30, 2025

@llvm/pr-subscribers-clang

Author: Fraser Cormack (frasercrmck)

Changes

As best as I can see, all NVPTX architectures support the generic address space.

I note there's a FIXME in the target's address space map about 'generic' still having to be added to the target but we haven't observed any issues with it downstream. The generic address space is mapped to the same target address space as default/private (0), but this isn't necessarily a problem for users.


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

2 Files Affected:

  • (modified) clang/lib/Basic/Targets/NVPTX.h (+2)
  • (modified) clang/test/Misc/nvptx.languageOptsOpenCL.cl (+8)
diff --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index dc1ecc30980b7..fbb46001b0f90 100644
--- a/clang/lib/Basic/Targets/NVPTX.h
+++ b/clang/lib/Basic/Targets/NVPTX.h
@@ -170,6 +170,8 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo : public TargetInfo {
     Opts["cl_khr_global_int32_extended_atomics"] = true;
     Opts["cl_khr_local_int32_base_atomics"] = true;
     Opts["cl_khr_local_int32_extended_atomics"] = true;
+
+    Opts["__opencl_c_generic_address_space"] = true;
   }
 
   const llvm::omp::GV &getGridValue() const override {
diff --git a/clang/test/Misc/nvptx.languageOptsOpenCL.cl b/clang/test/Misc/nvptx.languageOptsOpenCL.cl
index f479dddffb3ab..2610cfafc257b 100644
--- a/clang/test/Misc/nvptx.languageOptsOpenCL.cl
+++ b/clang/test/Misc/nvptx.languageOptsOpenCL.cl
@@ -132,3 +132,11 @@
 #pragma OPENCL EXTENSION cl_khr_subgroups: enable
 // expected-warning@-1{{unsupported OpenCL extension 'cl_khr_subgroups' - ignoring}}
 
+#if (__OPENCL_C_VERSION__ >= 300)
+#ifndef __opencl_c_generic_address_space
+#error "Missing __opencl_c_generic_address_space define"
+#else
+#error "Incorrect __opencl_c_generic_address_space define"
+#endif
+#pragma OPENCL EXTENSION __opencl_c_generic_address_space: enable
+#endif

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.

2 participants