[PATCH] D123803: [WIP][llvm] A Unified LTO Bitcode Frontend
Teresa Johnson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 18 10:05:22 PDT 2022
tejohnson added inline comments.
================
Comment at: llvm/lib/LTO/LTO.cpp:739
+ if (LTOMode == LTOK_UnifiedRegular)
+ if (NamedMDNode *CfiFunctionsMD = M.getNamedMetadata("cfi.functions"))
+ M.eraseNamedMetadata(CfiFunctionsMD);
----------------
Why is this needed?
================
Comment at: llvm/lib/LTO/LTO.cpp:1128
+ if (LTOMode == LTOKind::LTOK_UnifiedRegular)
+ EnableLTOInternalization = true;
+
----------------
Why is this needed?
================
Comment at: llvm/lib/LTO/LTO.cpp:1148
+ || GV->hasAppendingLinkage()))
+ continue;
+
----------------
Why is this needed?
================
Comment at: llvm/lib/LTO/LTO.cpp:1547
+ if (Conf.UnifiedLTO)
+ Conf.PTO.CallGraphProfile = false;
+
----------------
Why is this needed?
================
Comment at: llvm/lib/Transforms/IPO/PassManagerBuilder.cpp:212
PerformThinLTO = EnablePerformThinLTO;
+ UnifiedLTO = false;
DivergentTarget = false;
----------------
Rather than adding the many checks in the file below, can the Perform* and PrepareFor* options just be initialized differently under the UnifiedLTO mode?
================
Comment at: llvm/lib/Transforms/Utils/ModuleUtils.cpp:225
+ // When UnifiedLTO is enabled, we always need to generate split modules which
+ // requires a ModuleID. Using more types of metadata to generate this hash
----------------
As noted elsewhere, I'd prefer the UnifiedLTO not imply splitting. But regardless, this seems like a useful change whenever LTO unit is enabled - why not always compute the module hash this way?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D123803/new/
https://reviews.llvm.org/D123803
More information about the llvm-commits
mailing list