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

[Nick Sarnie via cfe-commits]

================
@@ -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 {
----------------
sarnex wrote:

`handleDeviceKernelAttr` calls `handleGlobalAttr` because `handleGlobalAttr` is the function that implements the CUDA-specific logic for global variables and kernels.  The code showing device kernels are expected is [here](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclAttr.cpp#L5024).

This attribute doesn't have any spellings for HIP or CUDA. There are only generic, OpenCL, NVPTX and AMDGPU spellings. Even before the change, there was no CUDA/HIP spelling. As the NVPTX spelling was only allowed for NVPTX targets, it was implicitly required that `handleGlobalAttr` is only called for NVPTX even though it handles CUDA.

I'm not sure I understand the comment about OpenCL semantics. The only OpenCL specific thing in that branch is skipping the error check as OpenCL throws a more specific one. `handleSimpleAttribute` does not assume any semantics of any language, it's called by basically every attribute to attach the attribute to the AST object.

The original motivation was to add a way to specify SPIR kernels in source code, and the first draft of the PR did that but I received strong feedback that we should not keep adding new attributes to specify kernels and combine the attributes. Feel free to look at the history of the PR or post your feedback to Erich and Aaron who supported this change, but I think it is difficult to have perfectly clean separation and no special handling in general for a large open source project like LLVM.

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