[Pipelines] Don't run module optimization in full LTO pre-link

[nikic]

Summary

When LTO is used, the pre-link pipeline is supposed to only perform module simplification, but not optimization. The post-link pipeline is responsible for optimization. In particular, we should not perform size increasing optimizations like loop vectorization and runtime unrolling before the second inlining run in the post-link pipeline.

This is already handled correctly by the thin LTO pipeline, but not the full LTO pipeline. This patch effectively makes the pre-link pipelines for thin/full LTO the same. (There is a minor difference in a single GlobalDCE run that possibly shouldn't be there, but I'm leaving it for now.)

[fhahn]

In general I think this is the right direction to go, but it would be good to have some performance data on the impact before going ahead, to catch any regressions beforehand.

[dmgreen]

I would be very surprised if this didn't cause some large regressions. I've always thought that one of the benefits for LTO is not just that it combines all function into a single module, but that it runs the pass pipeline twice.

[nikic]

In D148010#4258487, @dmgreen wrote:

I would be very surprised if this didn't cause some large regressions.

In theory this should be an improvement on both compile-time and performance. In practice, theory and practice probably don't match and this will be a mixed bag in terms of performance.

I've always thought that one of the benefits for LTO is not just that it combines all function into a single module, but that it runs the pass pipeline twice.

This is not an intended benefit of LTO, but it's indeed pretty plausible that LTO can paper over phase ordering issues.

I'd appreciate any help in evaluating performance for this change.

[aeubanks]

makes sense in theory since the module optimization pipeline really only needs to be run once per function, but it looks like there are some passes in the module optimization that aren't in the lto post-link pipeline, like RelLookupTableConverterPass, DivRemPairsPass, LoopSink

[nikic]

In D148010#4263777, @aeubanks wrote:

makes sense in theory since the module optimization pipeline really only needs to be run once per function, but it looks like there are some passes in the module optimization that aren't in the lto post-link pipeline, like RelLookupTableConverterPass, DivRemPairsPass, LoopSink

Good point. I've added LoopSink and DivRemPairs to the LTO pipeline in D148343. It's worth noting that these are close to useless in the pre-link pipeline, because they are de-canonicalizing transforms, which will get undone by the post-link passes. There is no point in running these pre-link.

I also happened across D148120 today, which is one of those cases where doing module optimization pre-link hurts optimization quality, because code gets vectorized pre-link before the trip count becomes known post-link.

[nikic]

Rebase and remove bits of dead code.

[dmgreen]

Hello. Did you manage to get anywhere with performance results?

[nikic]

In D148010#4281479, @dmgreen wrote:

Hello. Did you manage to get anywhere with performance results?

No yet. I had hoped that somebody with production non-thin LTO workloads would provide a performance evaluation. As that hasn't happened, I'll have to sanity check this on llvm-test-suite instead.

[dmgreen]

I have been trying to looks through our downstream performance differences, but they might be quite different to upstream. I think I can reduce or remove most of the regressions with pass pipeline changes in the test we have that run under LTO.

I have been looking at cases similar to D148120 recently. It's a problem we already knew about (https://reviews.llvm.org/D125301#3536693). But more than just predication, scalable vectorization in general will lead to loops without precise trip counts. I'm still not 100% sure this is the best, but we need to fix it in some way and for scalable vectors at least it makes sense to limit vectorization during the pre-lto step.

Unfortunately I think there might just be a lot of changes. The first thing to fix should probably be that the pass pipeline is different through addVectorPasses. There will be quite a few differences that come up from that.

[aeubanks]

@dmgreen how much work do you think it is to fix the regressions? I hear SLPVectorizer has code to not vectorize in some cases so that LTO post-link can vectorize better and this would simplify that.

[mehdi_amini]

Can you contrast this to the previous attempts like mine here: https://reviews.llvm.org/D29376 ?

[nikic]

In D148010#4357657, @mehdi_amini wrote:

Can you contrast this to the previous attempts like mine here: https://reviews.llvm.org/D29376 ?

As I commented on the other thread, the difference is that you replaced both the pre-link and the post-link pipelines, while this is only changing the pre-link pipeline. Fully aligning the post-link pipelines is a much more complex problem, in part because the full LTO post-link pipeline is compile-time sensitive, and in part because it is pretty much completely separate from all the other pipelines we have (which use minor variations of the general module simplification / module optimization framework). I think there are some things we can do to make the full LTO post-link pipeline closer to our other pipelines, but just replacing it with the thin LTO pipeline as you proposed is likely not going to be viable. (In particular, I believe it should be possible to mostly reuse the module optimization phase, but not the module simplification phase as-is.)

[mehdi_amini]

As far as I remember, there were a bunch of passes that are part of the compile-time phase that are not in the FullLTO link-time pipeline: if you just pruning all these from the compile-time phase, aren't we gonna miss on some optimization opportunities?
That is: passes that "shouldn't be run" during the compile-time are actually executed here because we don't have time-budget to run all this during the link-time (which in turns focuses on catching up on cross-module opt + lightweight pipeline).

Is there a thread on Discourse about this? I'm interested to see benchmarks numbers for this!

[nikic]

In D148010#4357721, @mehdi_amini wrote:

As far as I remember, there were a bunch of passes that are part of the compile-time phase that are not in the FullLTO link-time pipeline: if you just pruning all these from the compile-time phase, aren't we gonna miss on some optimization opportunities?
That is: passes that "shouldn't be run" during the compile-time are actually executed here because we don't have time-budget to run all this during the link-time (which in turns focuses on catching up on cross-module opt + lightweight pipeline).

To the most part, passes that are part of the module optimization phase do also get run post-link in full LTO (the big differences are before that -- the simplification phase is much reduced in full LTO and also does not use CGSCC interleaving). There is a small number of differences (e.g. missing loop load elimination) that I still plan to address. The probably more substantial problem is that while the right passes get run, they get run in the wrong order. In particular, runtime unrolling is performed before vectorization, rather than after. I plan to address these issues before moving forward with this patch, but not sure when I'll get around to it.

[smeenai]

We build Meta's Android apps with full LTO (paired with -Oz) and function merging to minimize size. I evaluated this patch as-is and it was a considerable size regression (526 KiB for Facebook for Android arm64). However, my colleague @lanza discovered that adding additional instances of the function merging pass (here, here, and here), in addition to being a considerable size improvement by itself, also makes this change be a small size improvement (20 KiB) instead. We haven't upstreamed the additional function merger runs yet (we want to make sure we understand the size improvements properly and have a principled reason for the change), but I figured I'd note it here early in case someone else is also evaluating this for size.

[lanza]

I evaluated this patch as-is and it was a considerable size regression (526 KiB for Facebook for Android arm64). However, my colleague @lanza discovered that adding additional instances of the function merging pass (here, here, and here), in addition to being a considerable size improvement by itself, also makes this change be a small size improvement (20 KiB) instead. We haven't upstreamed the additional function merger runs yet (we want to make sure we understand the size improvements properly and have a principled reason for the change), but I figured I'd note it here early in case someone else is also evaluating this for size.

To add a bit more detail here: we believe that the reason for this patch causing a regression (for us) is that running the function merging pass before LTO inlining (e.g. in the module optimization pipeline at the end of LTOprelink) causes a set of internal functions to become true for hasOneUse(). Thus the inliner will then boost the inline threshold, inline these functions, simplify them and generate size savings.

llvm/include/llvm/Passes/PassBuilder.h

public:
   /// build them.
   ModulePassManager
   buildModuleOptimizationPipeline(OptimizationLevel Level,
                                   ThinOrFullLTOPhase LTOPhase);
 
   /// Build a per-module default optimization pipeline.
   ///
   /// This provides a good default optimization pipeline for per-module
-  /// optimization and code generation without any link-time optimization. It
-  /// typically correspond to frontend "-O[123]" options for optimization
-  /// levels \c O1, \c O2 and \c O3 resp.
-  ModulePassManager buildPerModuleDefaultPipeline(OptimizationLevel Level,
-                                                  bool LTOPreLink = false);
+  /// optimization and code generation, and can also be configured for
+  /// pre-link optimization. It typically correspond to frontend "-O[123]"
+  /// options for optimization levels \c O1, \c O2 and \c O3 resp.
+  ModulePassManager buildPerModuleDefaultPipeline(
+      OptimizationLevel Level,
+      ThinOrFullLTOPhase Phase = ThinOrFullLTOPhase::None);
 
   /// Build a pre-link, ThinLTO-targeting default optimization pipeline to
   /// a pass manager.
   ///
   /// This adds the pre-link optimizations tuned to prepare a module for
   /// a ThinLTO run. It works to minimize the IR which needs to be analyzed
   /// without making irreversible decisions which could be made better during
   /// the LTO run.

llvm/lib/Passes/PassBuilderPipelines.cpp

void PassBuilder::addVectorPasses(OptimizationLevel Level,
 
   if (IsFullLTO)
     FPM.addPass(InstCombinePass());
 }
 
 ModulePassManager
 PassBuilder::buildModuleOptimizationPipeline(OptimizationLevel Level,
                                              ThinOrFullLTOPhase LTOPhase) {
-  const bool LTOPreLink = isLTOPreLink(LTOPhase);
+  assert(!isLTOPreLink(LTOPhase) && "Should not run during LTO pre-link");
   ModulePassManager MPM;
 
   // Run partial inlining pass to partially inline functions that have
   // large bodies.
   if (RunPartialInlining)
     MPM.addPass(PartialInlinerPass());
 
   // Remove avail extern fns and globals definitions since we aren't compiling
-  // an object file for later LTO. For LTO we want to preserve these so they
-  // are eligible for inlining at link-time. Note if they are unreferenced they
+  // an object file for later LTO. Note if they are unreferenced they
   // will be removed by GlobalDCE later, so this only impacts referenced
   // available externally globals. Eventually they will be suppressed during
   // codegen, but eliminating here enables more opportunity for GlobalDCE as it
   // may make globals referenced by available external functions dead and saves
   // running remaining passes on the eliminated functions. These should be
   // preserved during prelinking for link-time inlining decisions.
-  if (!LTOPreLink)
-    MPM.addPass(EliminateAvailableExternallyPass());
 
   if (EnableOrderFileInstrumentation)
     MPM.addPass(InstrOrderFilePass());
 
   // Do RPO function attribute inference across the module to forward-propagate
   // attributes where applicable.
   // FIXME: Is this really an optimization rather than a canonicalization?
   MPM.addPass(ReversePostOrderFunctionAttrsPass());
 
   // Do a post inline PGO instrumentation and use pass. This is a context
-  // sensitive PGO pass. We don't want to do this in LTOPreLink phrase as
-  // cross-module inline has not been done yet. The context sensitive
-  // instrumentation is after all the inlines are done.
-  if (!LTOPreLink && PGOOpt) {
+  // sensitive PGO pass.
+  if (PGOOpt) {
     if (PGOOpt->CSAction == PGOOptions::CSIRInstr)
       addPGOInstrPasses(MPM, Level, /* RunProfileGen */ true,
                         /* IsCS */ true, PGOOpt->CSProfileGenFile,
                         PGOOpt->ProfileRemappingFile, LTOPhase, PGOOpt->FS);
     else if (PGOOpt->CSAction == PGOOptions::CSIRUse)
       addPGOInstrPasses(MPM, Level, /* RunProfileGen */ false,
                         /* IsCS */ true, PGOOpt->ProfileFile,
                         PGOOpt->ProfileRemappingFile, LTOPhase, PGOOpt->FS);
PassBuilder::buildModuleOptimizationPipeline(OptimizationLevel Level,
   // function passes.
 
   for (auto &C : VectorizerStartEPCallbacks)
     C(OptimizePM, Level);
 
   LoopPassManager LPM;
   // First rotate loops that may have been un-rotated by prior passes.
   // Disable header duplication at -Oz.
-  LPM.addPass(LoopRotatePass(Level != OptimizationLevel::Oz, LTOPreLink));
+  LPM.addPass(LoopRotatePass(Level != OptimizationLevel::Oz));
   // Some loops may have become dead by now. Try to delete them.
   // FIXME: see discussion in https://reviews.llvm.org/D112851,
   //        this may need to be revisited once we run GVN before loop deletion
   //        in the simplification pipeline.
   LPM.addPass(LoopDeletionPass());
   OptimizePM.addPass(createFunctionToLoopPassAdaptor(
       std::move(LPM), /*UseMemorySSA=*/false, /*UseBlockFrequencyInfo=*/false));
 
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(OptimizePM),
                                                 PTO.EagerlyInvalidateAnalyses));
 
   for (auto &C : OptimizerLastEPCallbacks)
     C(MPM, Level);
 
   // Split out cold code. Splitting is done late to avoid hiding context from
   // other optimizations and inadvertently regressing performance. The tradeoff
   // is that this has a higher code size cost than splitting early.
-  if (EnableHotColdSplit && !LTOPreLink)
+  if (EnableHotColdSplit)
     MPM.addPass(HotColdSplittingPass());
 
   // Search the code for similar regions of code. If enough similar regions can
   // be found where extracting the regions into their own function will decrease
   // the size of the program, we extract the regions, a deduplicate the
   // structurally similar regions.
   if (EnableIROutliner)
     MPM.addPass(IROutlinerPass());
 
   // Merge functions if requested.
   if (PTO.MergeFunctions)
     MPM.addPass(MergeFunctionsPass());
 
   // Now we need to do some global optimization transforms.
   // FIXME: It would seem like these should come first in the optimization
   // pipeline and maybe be the bottom of the canonicalization pipeline? Weird
   // ordering here.
   MPM.addPass(GlobalDCEPass());
   MPM.addPass(ConstantMergePass());
 
-  if (PTO.CallGraphProfile && !LTOPreLink)
+  if (PTO.CallGraphProfile)
     MPM.addPass(CGProfilePass());
 
-  // TODO: Relative look table converter pass caused an issue when full lto is
-  // enabled. See https://reviews.llvm.org/D94355 for more details.
-  // Until the issue fixed, disable this pass during pre-linking phase.
-  if (!LTOPreLink)
-    MPM.addPass(RelLookupTableConverterPass());
 
   return MPM;
 }
 
 ModulePassManager
 PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
-                                           bool LTOPreLink) {
+                                           ThinOrFullLTOPhase Phase) {
   if (Level == OptimizationLevel::O0)
-    return buildO0DefaultPipeline(Level, LTOPreLink);
+    return buildO0DefaultPipeline(Level, isLTOPreLink(Phase));
 
   ModulePassManager MPM;
 
   // Convert @llvm.global.annotations to !annotation metadata.
   MPM.addPass(Annotation2MetadataPass());
 
   // Force any function attributes we want the rest of the pipeline to observe.
   MPM.addPass(ForceFunctionAttrsPass());
 
   if (PGOOpt && PGOOpt->DebugInfoForProfiling)
     MPM.addPass(createModuleToFunctionPassAdaptor(AddDiscriminatorsPass()));
 
   // Apply module pipeline start EP callback.
   for (auto &C : PipelineStartEPCallbacks)
     C(MPM, Level);
 
-  const ThinOrFullLTOPhase LTOPhase = LTOPreLink
-                                          ? ThinOrFullLTOPhase::FullLTOPreLink
-                                          : ThinOrFullLTOPhase::None;
   // Add the core simplification pipeline.
-  MPM.addPass(buildModuleSimplificationPipeline(Level, LTOPhase));
-
-  // Now add the optimization pipeline.
-  MPM.addPass(buildModuleOptimizationPipeline(Level, LTOPhase));
-
-  if (PGOOpt && PGOOpt->PseudoProbeForProfiling &&
-      PGOOpt->Action == PGOOptions::SampleUse)
-    MPM.addPass(PseudoProbeUpdatePass());
-
-  // Emit annotation remarks.
-  addAnnotationRemarksPass(MPM);
-
-  if (LTOPreLink)
-    addRequiredLTOPreLinkPasses(MPM);
-
-  return MPM;
-}
-
-ModulePassManager
-PassBuilder::buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level) {
-  if (Level == OptimizationLevel::O0)
-    return buildO0DefaultPipeline(Level, /*LTOPreLink*/true);
-
-  ModulePassManager MPM;
-
-  // Convert @llvm.global.annotations to !annotation metadata.
-  MPM.addPass(Annotation2MetadataPass());
-
-  // Force any function attributes we want the rest of the pipeline to observe.
-  MPM.addPass(ForceFunctionAttrsPass());
-
-  if (PGOOpt && PGOOpt->DebugInfoForProfiling)
-    MPM.addPass(createModuleToFunctionPassAdaptor(AddDiscriminatorsPass()));
-
-  // Apply module pipeline start EP callback.
-  for (auto &C : PipelineStartEPCallbacks)
-    C(MPM, Level);
-
-  // If we are planning to perform ThinLTO later, we don't bloat the code with
-  // unrolling/vectorization/... now. Just simplify the module as much as we
-  // can.
-  MPM.addPass(buildModuleSimplificationPipeline(
-      Level, ThinOrFullLTOPhase::ThinLTOPreLink));
+  MPM.addPass(buildModuleSimplificationPipeline(Level, Phase));
 
+  // If we are planning to perform LTO later, don't bloat the code with
+  // unrolling/vectorization/... now.
+  if (!isLTOPreLink(Phase)) {
+    MPM.addPass(buildModuleOptimizationPipeline(Level, Phase));
+  } else {
     // Run partial inlining pass to partially inline functions that have
     // large bodies.
     // FIXME: It isn't clear whether this is really the right place to run this
     // in ThinLTO. Because there is another canonicalization and simplification
     // phase that will run after the thin link, running this here ends up with
-  // less information than will be available later and it may grow functions in
-  // ways that aren't beneficial.
+    // less information than will be available later and it may grow functions
+    // in ways that aren't beneficial.
     if (RunPartialInlining)
       MPM.addPass(PartialInlinerPass());
 
-  if (PGOOpt && PGOOpt->PseudoProbeForProfiling &&
-      PGOOpt->Action == PGOOptions::SampleUse)
-    MPM.addPass(PseudoProbeUpdatePass());
-
     // Handle Optimizer{Early,Last}EPCallbacks added by clang on PreLink. Actual
     // optimization is going to be done in PostLink stage, but clang can't add
-  // callbacks there in case of in-process ThinLTO called by linker.
+    // callbacks there in case of in-process LTO called by linker.
     for (auto &C : OptimizerEarlyEPCallbacks)
       C(MPM, Level);
     for (auto &C : OptimizerLastEPCallbacks)
       C(MPM, Level);
+  }
+
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling &&
+      PGOOpt->Action == PGOOptions::SampleUse)
+    MPM.addPass(PseudoProbeUpdatePass());
 
   // Emit annotation remarks.
   addAnnotationRemarksPass(MPM);
 
+  if (isLTOPreLink(Phase))
     addRequiredLTOPreLinkPasses(MPM);
 
   return MPM;
 }
 
+ModulePassManager
+PassBuilder::buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level) {
+  return buildPerModuleDefaultPipeline(Level,
+                                       ThinOrFullLTOPhase::ThinLTOPreLink);
+}
+
 ModulePassManager PassBuilder::buildThinLTODefaultPipeline(
     OptimizationLevel Level, const ModuleSummaryIndex *ImportSummary) {
   ModulePassManager MPM;
 
   if (ImportSummary) {
     // These passes import type identifier resolutions for whole-program
     // devirtualization and CFI. They must run early because other passes may
     // disturb the specific instruction patterns that these passes look for,
ModulePassManager PassBuilder::buildThinLTODefaultPipeline(
   // Emit annotation remarks.
   addAnnotationRemarksPass(MPM);
 
   return MPM;
 }
 
 ModulePassManager
 PassBuilder::buildLTOPreLinkDefaultPipeline(OptimizationLevel Level) {
-  // FIXME: We should use a customized pre-link pipeline!
   return buildPerModuleDefaultPipeline(Level,
-                                       /* LTOPreLink */ true);
+                                       ThinOrFullLTOPhase::FullLTOPreLink);
 }
 
 ModulePassManager
 PassBuilder::buildLTODefaultPipeline(OptimizationLevel Level,
                                      ModuleSummaryIndex *ExportSummary) {
   ModulePassManager MPM;
 
   for (auto &C : FullLinkTimeOptimizationEarlyEPCallbacks)

llvm/test/Other/new-pm-defaults.ll

 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,CHECK-O23SZ,%llvmcheckext
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes='default<Os>' -S %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-NO-FUNC-SPEC,CHECK-Os,CHECK-O23SZ,%llvmcheckext
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes='default<Oz>' -S %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-NO-FUNC-SPEC,CHECK-Oz,CHECK-O23SZ,%llvmcheckext
-; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
-; RUN:     -passes='lto-pre-link<O2>' -S %s 2>&1 \
-; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-LTO,CHECK-NO-FUNC-SPEC,CHECK-O2,CHECK-O23SZ,%llvmcheckext
 
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes-ep-peephole='no-op-function' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-PEEPHOLE,CHECK-O23SZ
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes-ep-late-loop-optimizations='no-op-loop' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \

 ; RUN:     -passes-ep-pipeline-start='no-op-module' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-PIPELINE-START,CHECK-O23SZ
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes-ep-pipeline-early-simplification='no-op-module' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-PIPELINE-EARLY-SIMPLIFICATION,CHECK-O23SZ
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
-; RUN:     -passes-ep-pipeline-start='no-op-module' \
-; RUN:     -passes='lto-pre-link<O3>' -S  %s 2>&1 \
-; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-LTO,CHECK-NO-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-PIPELINE-START,CHECK-O23SZ
-; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes-ep-optimizer-early='no-op-module' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-OPTIMIZER-EARLY,CHECK-O23SZ
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes-ep-optimizer-last='no-op-module' \
 ; RUN:     -passes='default<O3>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-DEFAULT,CHECK-FUNC-SPEC,CHECK-O3,%llvmcheckext,CHECK-EP-OPTIMIZER-LAST,CHECK-O23SZ
 

 ; CHECK-O-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: InlineAdvisorAnalysis
 ; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: CoroCleanupPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: GlobalDCEPass
 ; CHECK-DEFAULT-NEXT: Running pass: EliminateAvailableExternallyPass
-; CHECK-LTO-NOT: Running pass: EliminateAvailableExternallyPass
 ; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
 ; CHECK-O-NEXT: Running pass: RecomputeGlobalsAAPass
 ; CHECK-EP-OPTIMIZER-EARLY: Running pass: NoOpModulePass
 ; CHECK-O-NEXT: Running pass: Float2IntPass
 ; CHECK-O-NEXT: Running pass: LowerConstantIntrinsicsPass on foo
 ; CHECK-MATRIX: Running pass: LowerMatrixIntrinsicsPass on f
 ; CHECK-MATRIX-NEXT: Running pass: EarlyCSEPass on f
 ; CHECK-O3-NEXT: Running pass: ControlHeightReductionPass

 ; CHECK-HOT-COLD-SPLIT-NEXT: Running pass: HotColdSplittingPass
 ; CHECK-IR-OUTLINER-NEXT: Running pass: IROutlinerPass
 ; CHECK-IR-OUTLINER-NEXT: Running analysis: IRSimilarityAnalysis
 ; CHECK-MERGE-FUNCS-NEXT: Running pass: MergeFunctionsPass
 ; CHECK-O-NEXT: Running pass: GlobalDCEPass
 ; CHECK-O-NEXT: Running pass: ConstantMergePass
 ; CHECK-DEFAULT-NEXT: Running pass: CGProfilePass
 ; CHECK-DEFAULT-NEXT: Running pass: RelLookupTableConverterPass
-; CHECK-LTO-NOT: Running pass: RelLookupTableConverterPass
 ; CHECK-O-NEXT: Running pass: AnnotationRemarksPass on foo
-; CHECK-LTO-NEXT: Running pass: CanonicalizeAliasesPass
-; CHECK-LTO-NEXT: Running pass: NameAnonGlobalPass
 ; CHECK-O-NEXT: Running pass: PrintModulePass
 ;
 ; Make sure we get the IR back out without changes when we print the module.
 ; CHECK-O-LABEL: define void @foo(i32 %n) local_unnamed_addr {
 ; CHECK-O-NEXT: entry:
 ; CHECK-O-NEXT:   br label %loop
 ; CHECK-O:      loop:
 ; CHECK-O-NEXT:   %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]

llvm/test/Other/new-pm-lto-prelink-defaults.ll

 ; RUN:     -passes='thinlto-pre-link<Os>' -S %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O23SZ,CHECK-O-NODIS
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
 ; RUN:     -passes='thinlto-pre-link<Oz>' -S %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O23SZ,CHECK-O-NODIS
 ; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager -debug-info-for-profiling \
 ; RUN:     -passes='thinlto-pre-link<O2>' -S  %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefixes=CHECK-DIS,CHECK-O,CHECK-O2,CHECK-O23SZ
-;
+
+; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
+; RUN:     -passes='lto-pre-link<O1>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O1,CHECK-O-NODIS,CHECK-FULL
+; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
+; RUN:     -passes='lto-pre-link<O2>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-O23SZ,CHECK-O-NODIS,CHECK-FULL
+; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
+; RUN:     -passes='lto-pre-link<Os>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O23SZ,CHECK-O-NODIS,CHECK-FULL
+; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
+; RUN:     -passes='lto-pre-link<Oz>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O23SZ,CHECK-O-NODIS,CHECK-FULL
+; RUN: opt -disable-verify -verify-analysis-invalidation=0 -eagerly-invalidate-analyses=0 -debug-pass-manager -debug-info-for-profiling \
+; RUN:     -passes='lto-pre-link<O2>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-DIS,CHECK-O,CHECK-O2,CHECK-O23SZ,CHECK-FULL
 
 ; Suppress FileCheck --allow-unused-prefixes=false diagnostics.
 ; CHECK-NOEXT: {{^}}
 
 ; CHECK-O: Running pass: Annotation2Metadata
 ; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
 ; CHECK-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
 ; CHECK-DIS-NEXT: Running analysis: InnerAnalysisManagerProxy

 ; CHECK-O-NEXT: Running analysis: ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Running pass: CoroSplitPass
 ; CHECK-O-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: ShouldNotRunFunctionPassesAnalysis
 ; CHECK-O-NEXT: Invalidating analysis: InlineAdvisorAnalysis
 ; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: CoroCleanupPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
+; CHECK-FULL-NEXT: Running pass: GlobalDCEPass
 ; CHECK-EXT: Running pass: {{.*}}::Bye
 ; CHECK-EP-OPT-EARLY-NEXT: Running pass: NoOpModulePass
 ; CHECK-EP-OPT-LAST-NEXT: Running pass: NoOpModulePass
 ; CHECK-O-NEXT:          Running pass: AnnotationRemarksPass on foo
 ; CHECK-O-NEXT: Running pass: CanonicalizeAliasesPass
 ; CHECK-O-NEXT: Running pass: NameAnonGlobalPass
 ; CHECK-O-NEXT: Running pass: PrintModulePass