[llvm] [LTO] Introduce a new class ImportIDTable (PR #106503)
Teresa Johnson via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 29 09:01:26 PDT 2024
================
@@ -96,6 +97,76 @@ class FunctionImporter {
std::tuple<unsigned, const GlobalValueSummary *,
std::unique_ptr<ImportFailureInfo>>>;
+ // Issues import IDs. Each ID uniquely corresponds to a tuple of
+ // (FromModule, GUID, Definition/Declaration).
+ //
+ // The import IDs make the import list space efficient by referring to each
+ // import with a 32-bit integer ID while maintaining a central table that maps
+ // those integer IDs to tuples of (FromModule, GUID, Def/Decl).
+ //
+ // In one large application, a pair of (FromModule, GUID) is mentioned in
+ // import lists more than 50 times on average across all destination modules.
+ // Mentioning the 32-byte tuple:
+ //
+ // std::tuple<StringRef, GlobalValue::GUID, GlobalValueSummary::ImportKind>
+ //
+ // 50 times by value in various import lists would be costly. We can reduce
+ // the memory footprint of import lists by placing one copy in a central table
+ // and referring to it with 32-bit integer IDs.
+ //
+ // To save space within the central table, we only store pairs of
+ // (FromModule, GUID) in the central table. In the actual 32-bit integer ID,
+ // the top 31 bits index into the central table while the bottom 1 bit
+ // indicates whether an ID is for GlobalValueSummary::Declaration or
+ // GlobalValueSummary::Definition.
+ class ImportIDTable {
+ public:
+ using ImportIDTy = uint32_t;
+
+ // Create a pair of import IDs [Def, Decl] for a given pair of FromModule
----------------
teresajohnson wrote:
In practice will we need both def and decl IDs returned?
https://github.com/llvm/llvm-project/pull/106503
More information about the llvm-commits
mailing list