================
@@ -1020,21 +1022,23 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
if (CodeGenOpts.FatLTO) {
- MPM = PB.buildFatLTODefaultPipeline(Level, PrepareForThinLTO,
- PrepareForThinLTO ||
- shouldEmitRegularLTOSummary());
+ MPM.addPass(PB.buildFatLTODefaultPipeline(
+ Level, PrepareForThinLTO,
+ PrepareForThinLTO || shouldEmitRegularLTOSummary()));
} else if (PrepareForThinLTO) {
- MPM = PB.buildThinLTOPreLinkDefaultPipeline(Level);
+ MPM.addPass(PB.buildThinLTOPreLinkDefaultPipeline(Level));
} else if (PrepareForLTO) {
- MPM = PB.buildLTOPreLinkDefaultPipeline(Level);
+ MPM.addPass(PB.buildLTOPreLinkDefaultPipeline(Level));
} else {
- MPM = PB.buildPerModuleDefaultPipeline(Level);
+ MPM.addPass(PB.buildPerModuleDefaultPipeline(Level));
}
}
// Add a verifier pass if requested. We don't have to do this if the action
// requires code generation because there will already be a verifier pass in
// the code-generation pipeline.
+ // Since we already added a verifier pass above, this
+ // might even not run the analysis, if previous passes caused no changes.
----------------
mizvekov wrote:
Yeah, that's what it says and is implemented here:
https://github.com/llvm/llvm-project/blob/0b07b06effe5fdf779b75bb5ac6cf15e477cb0be/llvm/include/llvm/IR/PassManager.h#L772
And it matches what I see when running the pass-manager debugger on O0 vs O1
builds, as you see on the changes affecting the
`clang/test/CodeGen/lto-newpm-pipeline.c` test. You can see for O0 that the
`VerifierPass` is executed a second time near the bottom, but that doesn't
trigger a `VerifierAnalysis` run.
https://github.com/llvm/llvm-project/pull/68015
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
