================
@@ -1530,14 +1530,11 @@
PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
}
ModulePassManager
-PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level, bool ThinLTO,
- bool EmitSummary) {
+PassBuilder::buildFatLTODefaultPipeline(OptimizationLevel Level) {
ModulePassManager MPM;
- MPM.addPass(EmbedBitcodePass(ThinLTO, EmitSummary,
- ThinLTO
- ? buildThinLTOPreLinkDefaultPipeline(Level)
- : buildLTOPreLinkDefaultPipeline(Level)));
- MPM.addPass(buildPerModuleDefaultPipeline(Level));
+ MPM.addPass(buildThinLTOPreLinkDefaultPipeline(Level));
+ MPM.addPass(EmbedBitcodePass());
+ MPM.addPass(buildThinLTODefaultPipeline(Level, /*ImportSummary=*/nullptr));
----------------
teresajohnson wrote:
What was the downside of using ThinLTODefaultPipeline always? I guess it was
essentially over-optimizing in the non-LTO case? I guess using the
ThinLTODefaultPipeline only under SamplePGO is ok with me, although it seems
like over time as the pipelines get modified it will be difficult to ensure
that is the only case where the pipelines get out of sync. I think in either
case we are essentially saying: if you use Fat LTO then don't expect the
resulting non-LTO native code to be the same as that of a fully non-LTO
compile. In one case there is more optimization, in the other there is the risk
of future deoptimization if things don't stay in sync.
https://github.com/llvm/llvm-project/pull/72180
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
