We were emitting construction v-tables with internal linkage all the time.
Emit them instead with the linkage of the VTT.
I'm actually really ambivalent about this; it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant. Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors; giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.
llvm-svn: 128374
diff --git a/clang/lib/CodeGen/CGVTables.cpp b/clang/lib/CodeGen/CGVTables.cpp
index 6c1b331..17d3cde 100644
--- a/clang/lib/CodeGen/CGVTables.cpp
+++ b/clang/lib/CodeGen/CGVTables.cpp
@@ -3065,6 +3065,7 @@
CodeGenVTables::GenerateConstructionVTable(const CXXRecordDecl *RD,
const BaseSubobject &Base,
bool BaseIsVirtual,
+ llvm::GlobalVariable::LinkageTypes Linkage,
VTableAddressPointsMapTy& AddressPoints) {
VTableBuilder Builder(*this, Base.getBase(),
CGM.getContext().toBits(Base.getBaseOffset()),
@@ -3093,8 +3094,11 @@
// Create the variable that will hold the construction vtable.
llvm::GlobalVariable *VTable =
- CGM.CreateOrReplaceCXXRuntimeVariable(Name, ArrayType,
- llvm::GlobalValue::InternalLinkage);
+ CGM.CreateOrReplaceCXXRuntimeVariable(Name, ArrayType, Linkage);
+ CGM.setTypeVisibility(VTable, RD, CodeGenModule::TVK_ForConstructionVTable);
+
+ // V-tables are always unnamed_addr.
+ VTable->setUnnamedAddr(true);
// Add the thunks.
VTableThunksTy VTableThunks;