================
@@ -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:
The plumbing's already there though - and means one source of truth that both
the consumer of the .pcm and the compilation of the .pcm->.o step use - rather
than two separate pieces of code that also have to be kept in sync. (and the
code's already there, the check before the one this patch proposes to be added
to `isConsumerInterestedIn` is the modular code generation codepath already -
and the populating of `ModularCodegenDecls` is part of that system)
I'd rather not add ad-hoc hardcoded things across these several places when we
have a mechanism to use that gets set at .pcm time, is (sort of) generic across
that for the usage and the implementation compilation.
It seems like fine existing infrastructure to further generalize to handle
home-able types (that can be homed for code generation reasons, as well as for
debug info reasons).
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
