[clang] [clang] Ensure we don't process OpenCL kernels as CUDA kernels (PR #163859)

Tom Honermann via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 27 09:45:37 PDT 2025


================
@@ -5206,7 +5206,8 @@ static void handleCallConvAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
 static void handleDeviceKernelAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   const auto *FD = dyn_cast_or_null<FunctionDecl>(D);
   bool IsFunctionTemplate = FD && FD->getDescribedFunctionTemplate();
-  if (S.getASTContext().getTargetInfo().getTriple().isNVPTX()) {
+  if (S.getASTContext().getTargetInfo().getTriple().isNVPTX() &&
+      !DeviceKernelAttr::isOpenCLSpelling(AL)) {
     handleGlobalAttr(S, D, AL);
   } else {
----------------
tahonermann wrote:

That branching is exactly my concern; it doesn't make sense to assume OpenCL semantics are intended for a non-OpenCL spelling and a non-NVPTX target. The branch that calls `handleGlobalAttr()` should be entered for a CUDA/HIP spelling regardless of the target. Note that this branching structure was introduced by commit 3b9ebe92011b033523217a9b9a2f03f4c8c37aab.

Actually, why is `handleDeviceKernelAttr()` trying to call `handleGlobalAttr()` at all? `handleDeviceKernelAttr()` is only called for `AT_DeviceKernel`. `handleGlobalAttr()` handles `AT_CUDAGlobal` and `CUDAGlobalAttr` remains separate from `DeviceKernelAttr`.

The more I look at the residual effects of the merge of device kernel attributes, the more I think it was not a well motivated or positive change.

https://github.com/llvm/llvm-project/pull/163859


More information about the cfe-commits mailing list