Link jumptable attributes consistently with unnamed_addr

[tmroeder]

Summary

This patch changes the module linker to not unset unnamed_addr on merged functions that have the jumptable attribute. As the test case demonstrates, this can happen with a declaration that has no jumptable attribute and no unnamed_addr when it is linked with a defined function that has both.

[tmroeder]

ping

[tmroeder]

ping

[• rafael]

lib/Linker/LinkModules.cpp

1029

Shouldn't it drop the jumptable instead? Or report an error?

If unnamed_addr is not present in a module, then that module can depend on the address of that GV. Adding it also produces an invalid module.

[tmroeder]

This is very old and doesn't need to be open anymore.

lib/Linker/LinkModules.cpp

bool ModuleLinker::linkGlobalValueProto(GlobalValue *SGV) {
   } else {
     NewGV = linkGlobalAliasProto(cast<GlobalAlias>(SGV), DGV, LinkFromSrc);
   }
 
   if (NewGV) {
     if (NewGV != DGV)
       copyGVAttributes(NewGV, SGV);
 
+    // Don't unset unnamed_addr on values with a jumptable attribute, since that
+    // leads to an invalid module.
+    if (Function *NewGVF = dyn_cast<Function>(NewGV))
+      if (NewGVF->hasFnAttribute(Attribute::JumpTable))
+        HasUnnamedAddr = true;
+
     NewGV->setUnnamedAddr(HasUnnamedAddr);
     NewGV->setVisibility(Visibility);
 
     if (auto *NewGO = dyn_cast<GlobalObject>(NewGV)) {
       if (C)
         NewGO->setComdat(C);
     }
 

test/Linker/jumptable-a.ll

+; RUN: llvm-link %s %p/jumptable-b.ll -S -o - | FileCheck %s
+declare void @f()
+; CHECK: ; Function Attrs: jumptable
+; CHECK: define void @f() unnamed_addr #0 {

test/Linker/jumptable-b.ll

+; RUN: true
+define void @f() unnamed_addr jumptable {
+  ret void
+}