[CUDA][HIP] Don't set "comdat" attribute for CUDA device stub functions.

[kpyzhov]

Summary

When compiling the HOST part of CUDA programs, clang replaces device kernels with so-called "stub" functions that contains a few calls to the Runtime API functions (which set the kernel argument values and launch the kernel itself). The stub functions are very small, so they may have identical generated code for different kernels with same arguments.
The Microsoft Linker has an optimization called "COMDAT Folding". It's able to detect functions with identical binary code and "merge" them, i.e. replace calls and pointers to those different functions with call/pointer to one of them and eliminate other copies.

Here is the description of this optimization: https://docs.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=vs-2019
That page contains a warning about "COMDAT Folding":
"Because /OPT:ICF can cause the same address to be assigned to different functions or read-only data members (that is, const variables when compiled by using /Gy), it can break a program that depends on unique addresses for functions or read-only data members."
That's exactly what happens to the CUDA stub functions.

This change disables setting "COMDAT" attribute for CUDA stub functions in the HOST code.

[tra]

SGTM in principle. Folding the stubs would be bad as their addresses are implicitly used to identify the kernels to launch.

clang/lib/CodeGen/CodeGenModule.cpp

4294

Perhaps this should be pushed further down into shouldBeInCOMDAT() which seems to be the right place to decide whether something is not suitable for comdat.

[kpyzhov]

clang/lib/CodeGen/CodeGenModule.cpp

4294

Good idea. Let me do that.

[rjmccall]

This optimization is disabled for functions not in COMDAT sections? Is that documented somewhere?

[kpyzhov]

In D63277#1550870, @rjmccall wrote:

This optimization is disabled for functions not in COMDAT sections? Is that documented somewhere?

It is documented here: https://docs.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=vs-2019

[rjmccall]

Alright, thanks. I agree that per the documentation this should be sufficient.

clang/lib/CodeGen/CodeGenModule.cpp

void CodeGenModule::MaybeHandleStaticInExternC(const SomeDecl *D,
   if (!R.second)
     R.first->second = nullptr;
 }
 
 static bool shouldBeInCOMDAT(CodeGenModule &CGM, const Decl &D) {
   if (!CGM.supportsCOMDAT())
     return false;
 
+  // Do not set COMDAT attribute for CUDA/HIP stub functions to prevent
+  // them being "merged" by the COMDAT Folding linker optimization.
+  if (D.hasAttr<CUDAGlobalAttr>())
+    return false;
+
   if (D.hasAttr<SelectAnyAttr>())
     return true;
 
   GVALinkage Linkage;
   if (auto *VD = dyn_cast<VarDecl>(&D))
     Linkage = CGM.getContext().GetGVALinkageForVariable(VD);
   else
     Linkage = CGM.getContext().GetGVALinkageForFunction(cast<FunctionDecl>(&D));
void CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
   // generating code for it because various parts of IR generation
   // want to propagate this information down (e.g. to local static
   // declarations).
   auto *Fn = cast<llvm::Function>(GV);
   setFunctionLinkage(GD, Fn);
 
   // FIXME: this is redundant with part of setFunctionDefinitionAttributes
   setGVProperties(Fn, GD);
 
   MaybeHandleStaticInExternC(D, Fn);
 
 
   maybeSetTrivialComdat(*D, *Fn);
 
   CodeGenFunction(*this).GenerateCode(D, Fn, FI);
 
   setNonAliasAttributes(GD, Fn);