================
@@ -5465,15 +5465,19 @@ static void handleGlobalAttr(Sema &S, Decl *D, const 
ParsedAttr &AL) {
   if (FD->isInlineSpecified() && !S.getLangOpts().CUDAIsDevice)
     S.Diag(FD->getBeginLoc(), diag::warn_kern_is_inline) << FD;
 
-  if (AL.getKind() == ParsedAttr::AT_DeviceKernel)
-    D->addAttr(::new (S.Context) DeviceKernelAttr(S.Context, AL));
-  else
+  // ***REVIEWER***: the existing code clearly expects either DeviceKernel or
+  // Global, and no others, but this does not appear to be made explicit?
+  if (AL.getKind() == ParsedAttr::AT_DeviceKernel) {
+    if (!D->hasAttr<DeviceKernelAttr>())
+      D->addAttr(::new (S.Context) DeviceKernelAttr(S.Context, AL));
+  } else if (!D->hasAttr<CUDAGlobalAttr>())
     D->addAttr(::new (S.Context) CUDAGlobalAttr(S.Context, AL));
+
   // In host compilation the kernel is emitted as a stub function, which is
   // a helper function for launching the kernel. The instructions in the helper
   // function has nothing to do with the source code of the kernel. Do not emit
   // debug info for the stub function to avoid confusing the debugger.
-  if (S.LangOpts.HIP && !S.LangOpts.CUDAIsDevice)
+  if (S.LangOpts.HIP && !S.LangOpts.CUDAIsDevice && !D->hasAttr<NoDebugAttr>())
     D->addAttr(NoDebugAttr::CreateImplicit(S.Context));
----------------
steffenlarsen wrote:

Relying on deduplication as part of `addAttr` would arguably also be an 
anti-pattern, given that in cases like these we would be paying for the 
construction of the attribute just to potentially drop it.

I suppose maybe there could be use of some merging logic, like we do in other 
places, but generalizing and always assuming that it is the programmers 
intention when they call `addAttr` is probably dangerous. In a case like that I 
would rather it be a separate `addOrMergeAttr`.

> Some way of assertion non-duplicate-safe attrs might be nice, which I think 
> should have caught this one

I'd be all for that.

https://github.com/llvm/llvm-project/pull/218582
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to