================
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the class is templated, the tables are emitted in every object that
+ // references any of them.
+ // - Otherwise, if the class is attached to a module, the tables are uniquely
+ // emitted in the object for the module unit in which it is defined.
+ // - Otherwise, if the class has a key function (see below), the tables are
+ // emitted in the object for the translation unit containing the definition
of
+ // the key function. This is unique if the key function is not inline.
+ // - Otherwise, the tables are emitted in every object that references any of
+ // them.
+ if (Module *M = RD->getOwningModule(); M && M->isNamedModule())
----------------
dwblaikie wrote:
Rather than doing this based on a named module, I wonder if this could be
powered by the same system that originally worked for clang header modular code
generation. It worked/works by adding a bit to declarations about whether to
home them to a modular object file
e6b7c28d17edf428c58ba65c549109c0a488a5be
Though I guess in 1ac9c98e6c40d9a1e6cb904b414161388af4a89c I used the bit on a
type to mean "home this type in debug info" and the bit on a function to mean
"home this function's code" - so I'm not sure what we'd do to track the vtable
specifically... Maybe not worth it/not feasible, not sure.
https://github.com/llvm/llvm-project/pull/75912
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
