[PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.

[chandlerc]

Summary

Based on the original patch by Davide, but I've adjusted the API exposed
to just be different entry points rather than exposing more state
parameters. I've factored all the common logic out so that we don't have
any duplicate pipelines, we just stitch them together in different ways.
I think this makes the build easier to reason about and understand.

This adds a direct method for getting the module simplification pipeline
as well as a method to get the optimization pipeline. While not my
express goal, this seems nice and gives a good place comment about the
restrictions that are imposed on them.

I did make some minor changes to the way the pipelines are structured
here, but hopefully not ones that are significant or controversial:

1. I sunk the PGO indirect call promotion to only be run when we have PGO enabled (or as part of the special ThinLTO pipeline).

2. I made the extra GlobalOpt ron in ThinLTO just happen all the time and at a slightly more powerful place (before we remove available externaly functions). This seems like general goodness and not a big compile time sink, so it didn't make sense to *only* use it in ThinLTO. Fewer differences in the pipeline makes everything simpler IMO.

3. I hoisted the ThinLTO stop point pre-link above the partial inliner and the RPO function attr inference. Partial inlining isn't going to make the code smaller and it seems better to just do that once post-link. And the RPO inference won't infer anything terribly meaningful pre-link (recursiveness?) so it didn't make a lot of sense. But if teh RPO inference starts to matter, we should move it to the canonicalization phase anyways which seems like a better place for it (and there is a FIXME to this effect!). But that seemed a bridge too far for this patch.

If we ever need to parameterize these pipelines more heavily, we can
always sink the logic to helper functions with parameters to keep those
parameters out of the public API. But the changes above seemed minor
that we could possible get away without the parameters entirely.

Lastly, this factoring does introduce a nesting layer of module pass
managers in the default pipeline. I don't think this is a big deal and
the flexibility of decoupling the pipelines seems easily worth it.

[tejohnson]

I hoisted the ThinLTO stop point pre-link above the partial inliner and the RPO function attr inference. Partial inlining isn't going to make the code smaller and it seems better to just do that once post-link.

Added davidxl to comment on this change. It seems like doing some partial inlining during the pre-link for ThinLTO will have an effect on the importing. Also, it is pre-link (as well as post-link) in the old pass pipeline, so this would introduce an inconsistency between the pass pipelines. May be better to keep it in the same places, and evaluate the effect of removing it from the pre-link pass pipeline separately?

lib/Passes/PassBuilder.cpp

583 ↗

(On Diff #100214)

s/if/since/ (we aren't compiling an object file for later LTO). Since we don't invoke this in the pre-link *LTO pipelines.

708 ↗

(On Diff #100214)

I don't see this getting invoked.

[chandlerc]

In D33540#764460, @tejohnson wrote:

I hoisted the ThinLTO stop point pre-link above the partial inliner and the RPO function attr inference. Partial inlining isn't going to make the code smaller and it seems better to just do that once post-link.

Added davidxl to comment on this change. It seems like doing some partial inlining during the pre-link for ThinLTO will have an effect on the importing. Also, it is pre-link (as well as post-link) in the old pass pipeline, so this would introduce an inconsistency between the pass pipelines. May be better to keep it in the same places, and evaluate the effect of removing it from the pre-link pass pipeline separately?

Well, partial inliner isn't run at all yet. So my hope was it can get moved around later.

I somewhat wanted to make the split line up with the simplification split that is already there in the pipeline. But if you feel strongly we need to keep these exactly the same, I can essentially copy the extra passes into the tail of the thinlto prelink stuff.

lib/Passes/PassBuilder.cpp

708 ↗

(On Diff #100214)

Yeah, the original patch had a change to Clang, but I wanted to get a submittable LLVM-focused version.

I'll add support for parsing these pipelines much like we support parsing 'default<O2>' and such so that we have some coverage of stuff.

[davidxl]

For partial inlining, leave it consistent with old PM for now. We can introduce later an internal option to enable/disable pre-thin-link partial inlining and collect more performance number.

[chandlerc]

In D33540#764937, @davidxl wrote:

For partial inlining, leave it consistent with old PM for now. We can introduce later an internal option to enable/disable pre-thin-link partial inlining and collect more performance number.

Is there a rationale for the position in the old PM? Was this discussed somewhere? I'd almost rather adjust the position in the old PM to be consistent with here. Without data, I think the position I gave it here actually fits with the clear intent indicated by the comments. The previous position, honestly, looked like an accident to me. Maybe it isn't but I couldn't find any really clear reason written down anywhere, and the only test that fails if I reorder these things is just the one that asserts a particular order.

Anyways, I'll change this back to the old PM one for now, but I really do want to understand why this is the right initial ordering to use.

[tejohnson]

In D33540#765031, @chandlerc wrote:

In D33540#764937, @davidxl wrote:

For partial inlining, leave it consistent with old PM for now. We can introduce later an internal option to enable/disable pre-thin-link partial inlining and collect more performance number.

Is there a rationale for the position in the old PM? Was this discussed somewhere? I'd almost rather adjust the position in the old PM to be consistent with here. Without data, I think the position I gave it here actually fits with the clear intent indicated by the comments. The previous position, honestly, looked like an accident to me. Maybe it isn't but I couldn't find any really clear reason written down anywhere, and the only test that fails if I reorder these things is just the one that asserts a particular order.

Anyways, I'll change this back to the old PM one for now, but I really do want to understand why this is the right initial ordering to use.

Thanks - I'd like the ability to be able to enable/disable it in the pre-link optimization step when I test its performance with ThinLTO.

[davidxl]

I was aware that partial inlining is available in both pre and post link thinLTO pipelines. It is just not tuned. In fact, the right thing to do for ThinLTO is only do function outlining in the prelink step -- this will shrink function size and exposes more importing. The regular inliner in the post -link phase can handle those functions properly. Post thin-link needs another round of partial inlining after the inliner.

[chandlerc]

In D33540#765076, @davidxl wrote:

I was aware that partial inlining is available in both pre and post link thinLTO pipelines. It is just not tuned. In fact, the right thing to do for ThinLTO is only do function outlining in the prelink step -- this will shrink function size and exposes more importing. The regular inliner in the post -link phase can handle those functions properly. Post thin-link needs another round of partial inlining after the inliner.

It sounds like the work around partial inlining really needs a wider discussion around the right design and approach. I can't find any RFC or other discussion about it. Could you write up your plans here and send them out? I think that would be very helpful.

When I discussed this a month or 2 ago with Davide I mentioned the long discussion I had about 5 years ago with Owen, Jakub, Eric, and others in the LLVM community around this. At the time, Owen strongly advised against using PartialInlining at all and to focus entirely on outlining to allow the normal inliner to do the partial inlining phase. That was a *long* time ago and so it may no longer be relevant, but we should at least have a pretty clear plan, rationale, concerns/tradeoffs discussion on the dev list.

[chandlerc]

Address comments from both Teresa and David. Moved PartialIniling to run both
before and after thin link along with a FIXME to revisit the correct placement
of this pass long term.

Added testing facilities for the ThinLTO pipelines.

[mehdi_amini]

In D33540#765031, @chandlerc wrote:

In D33540#764937, @davidxl wrote:

For partial inlining, leave it consistent with old PM for now. We can introduce later an internal option to enable/disable pre-thin-link partial inlining and collect more performance number.

Is there a rationale for the position in the old PM? Was this discussed somewhere?

Do you really think I flipped a coin? git log/git blame easily find the original review that introduced the ThinLTO pipeline: http://reviews.llvm.org/D17115

I'd almost rather adjust the position in the old PM to be consistent with here.

What data do you have? Your intuition alone is not a reason to go over the extensive tests we've been doing before setting it up the way it is. The pipeline is what it is now because I started with the same "intuition" and "rational" as you do, and tried to not perform inlining. However I did a bunch of measurement before landing it, and had to realize that (at that time at least), the bitcode was much larger, there were more functions to be imported, and it slowed down the compile time significantly (I'm not saying it is still the case, I don't know, but I don't see data here).

See also later tweaking in: http://reviews.llvm.org/D19773 that shifted more work from the thin-backend to the compile phase, which helped a lot building LLVM (since the compile-phase happens once per file while the Thin-backends run for every binary that is linked).

include/llvm/Passes/PassBuilder.h

256 ↗

(On Diff #100328)

It is the first time I see "prelink" to describe the compile phase. I find this confusing. The "link" happens after ThinLTO, we never link the IR in ThinLTO.

[mehdi_amini]

Note: the plan was to tune the inliner heuristic in the compile phase differently from the thin-backends phase, but we never got to it. It is also already challenging to maintain and evolve the existing thresholds, that I'm not sure adding another "optimization goal" is sustainable.

[mehdi_amini]

Indeed, looks like the buildModuleSimplificationPipeline got me confused with buildFunctionSimplificationPipeline, sorry /me -> []

[chandlerc]

In D33540#765851, @mehdi_amini wrote:

In D33540#765031, @chandlerc wrote:

In D33540#764937, @davidxl wrote:

For partial inlining, leave it consistent with old PM for now. We can introduce later an internal option to enable/disable pre-thin-link partial inlining and collect more performance number.

Is there a rationale for the position in the old PM? Was this discussed somewhere?

Do you really think I flipped a coin? git log/git blame easily find the original review that introduced the ThinLTO pipeline: http://reviews.llvm.org/D17115

Just to fully close the loop on this: as David said this was *only* a question about the partial inliner (I'm aware of the clear discussion around the larger ThinLTO pipeline).

And even then, I absolutely don't believe it was "flipping a coin". =] I can imagine that there was some clear rationale and it maybe didn't get written down, or that there wasn't enough information at the time which is also fine but useful to understand when making subsequent decisions.

I'd almost rather adjust the position in the old PM to be consistent with here.

What data do you have? Your intuition alone is not a reason to go over the extensive tests we've been doing before setting it up the way it is. The pipeline is what it is now because I started with the same "intuition" and "rational" as you do, and tried to not perform inlining. However I did a bunch of measurement before landing it, and had to realize that (at that time at least), the bitcode was much larger, there were more functions to be imported, and it slowed down the compile time significantly (I'm not saying it is still the case, I don't know, but I don't see data here).

Yeah, sorry, this all only makes sense for *partial inlining*, not for the rest of it. Anyways... Sorry for confusion.

And even then, I want to be clear that if there have been extensive tests that show that the partial inliner needs to have a particular location, clearly that is more important. I just wasn't finding any documentation trail pointing at these results, and I think that if we actually have something better than intuition, it is important to document it where possible.

include/llvm/Passes/PassBuilder.h

256 ↗

(On Diff #100328)

We don't link the IR, but we do something called 'thin link' which this is before, and so 'pre-link' didn't seem completely crazy to me.

It also has the advantage of matching the terminology used for normal LTO...

But I'm totally open to a better set of terminology here if you have some in mind. I'm worried that 'compile' may be too generic, but maybe it isn't. Thoughts?

[chandlerc]

(FYI, I think this is ready for another look, only outstanding issue I'm aware of is Mehdi's concern around 'pre-link' terminology and that really just needs anyone else with naming thoughts to chime in...)

[echristo]

In D33540#766418, @chandlerc wrote:

(FYI, I think this is ready for another look, only outstanding issue I'm aware of is Mehdi's concern around 'pre-link' terminology and that really just needs anyone else with naming thoughts to chime in...)

FWIW I like both the name and the consistency...

I've also taken a quick look and other than a complaint about boolean parameters it looks ok to me.

lib/LTO/LTOBackend.cpp

140 ↗

(On Diff #100328)

Boolean arguments are terrible. I don't have any better ideas at the moment that don't involve wide refactoring though.

[mehdi_amini]

In D33540#766416, @chandlerc wrote:

Yeah, sorry, this all only makes sense for *partial inlining*, not for the rest of it. Anyways... Sorry for confusion.

Well, that was my bad for misunderstanding the context of your discussion! :)

include/llvm/Passes/PassBuilder.h

256 ↗

(On Diff #100328)

I can just speak to myself: when I read "link" without more precision I think about the native link, that happens after LTO completes, so pre-link makes me think about right before it. But if I'm the only one to read it this way, forget it.

I never liked any of the naming around ThinLTO anyway: the backends without more precision are confusing with the LLVM target backends as well, and as you mention compile is quite generic and confusing. I try to be consistent and say "compile phase" and "thin backends" all the time when I have to refer to these.

[chandlerc]

Ping? I think I've addressed all the comments... Other patches are kinda blocked on this...

[davide]

Just few comments.

lib/Passes/PassBuilder.cpp

751 ↗

(On Diff #100328)

s/te/to/ I guess.

995–997 ↗

(On Diff #100328)

this and the one below could be factored out in a single helper so we don't have to change two cases. It can be a follow-up.

[chandlerc]

Thanks, landing with suggested fixes. (I also confirmed with David and Mehdi that they were happy.)

llvm/trunk/include/llvm/Passes/PassBuilder.h

public:
   /// Note that \p Level cannot be `O0` here. The pipelines produced are
   /// only intended for use when attempting to optimize code. If frontends
   /// require some transformations for semantic reasons, they should explicitly
   /// build them.
   FunctionPassManager
   buildFunctionSimplificationPipeline(OptimizationLevel Level,
                                       bool DebugLogging = false);
 
+  /// Construct the core LLVM module canonicalization and simplification
+  /// pipeline.
+  ///
+  /// This pipeline focuses on canonicalizing and simplifying the entire module
+  /// of IR. Much like the function simplification pipeline above, it is
+  /// suitable to run repeatedly over the IR and is not expected to destroy
+  /// important information. It does, however, perform inlining and other
+  /// heuristic based simplifications that are not strictly reversible.
+  ///
+  /// Note that \p Level cannot be `O0` here. The pipelines produced are
+  /// only intended for use when attempting to optimize code. If frontends
+  /// require some transformations for semantic reasons, they should explicitly
+  /// build them.
+  ModulePassManager
+  buildModuleSimplificationPipeline(OptimizationLevel Level,
+                                    bool DebugLogging = false);
+
+  /// Construct the core LLVM module optimization pipeline.
+  ///
+  /// This pipeline focuses on optimizing the execution speed of the IR. It
+  /// uses cost modeling and thresholds to balance code growth against runtime
+  /// improvements. It includes vectorization and other information destroying
+  /// transformations. It also cannot generally be run repeatedly on a module
+  /// without potentially seriously regressing either runtime performance of
+  /// the code or serious code size growth.
+  ///
+  /// Note that \p Level cannot be `O0` here. The pipelines produced are
+  /// only intended for use when attempting to optimize code. If frontends
+  /// require some transformations for semantic reasons, they should explicitly
+  /// build them.
+  ModulePassManager buildModuleOptimizationPipeline(OptimizationLevel Level,
+                                                    bool DebugLogging = false);
+
   /// 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.
   ///
   /// Note that \p Level cannot be `O0` here. The pipelines produced are
   /// only intended for use when attempting to optimize code. If frontends
   /// require some transformations for semantic reasons, they should explicitly
   /// build them.
   ModulePassManager buildPerModuleDefaultPipeline(OptimizationLevel Level,
                                                   bool DebugLogging = false);
 
+  /// 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.
+  ///
+  /// Note that \p Level cannot be `O0` here. The pipelines produced are
+  /// only intended for use when attempting to optimize code. If frontends
+  /// require some transformations for semantic reasons, they should explicitly
+  /// build them.
+  ModulePassManager
+  buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level,
+                                     bool DebugLogging = false);
+
+  /// Build an ThinLTO default optimization pipeline to a pass manager.
+  ///
+  /// This provides a good default optimization pipeline for link-time
+  /// optimization and code generation. It is particularly tuned to fit well
+  /// when IR coming into the LTO phase was first run through \c
+  /// addPreLinkLTODefaultPipeline, and the two coordinate closely.
+  ///
+  /// Note that \p Level cannot be `O0` here. The pipelines produced are
+  /// only intended for use when attempting to optimize code. If frontends
+  /// require some transformations for semantic reasons, they should explicitly
+  /// build them.
+  ModulePassManager buildThinLTODefaultPipeline(OptimizationLevel Level,
+                                                bool DebugLogging = false);
+
   /// Build a pre-link, LTO-targeting default optimization pipeline to a pass
   /// manager.
   ///
   /// This adds the pre-link optimizations tuned to work well with a later LTO
   /// 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/trunk/lib/LTO/LTOBackend.cpp

else
     RelocModel =
         M.getPICLevel() == PICLevel::NotPIC ? Reloc::Static : Reloc::PIC_;
 
   return std::unique_ptr<TargetMachine>(TheTarget->createTargetMachine(
       TheTriple, Conf.CPU, Features.getString(), Conf.Options, RelocModel,
       Conf.CodeModel, Conf.CGOptLevel));
 }
 
-static void runNewPMPasses(Module &Mod, TargetMachine *TM, unsigned OptLevel) {
+static void runNewPMPasses(Module &Mod, TargetMachine *TM, unsigned OptLevel,
+                           bool IsThinLTO) {
   PassBuilder PB(TM);
   AAManager AA;
 
   // Parse a custom AA pipeline if asked to.
   assert(PB.parseAAPipeline(AA, "default"));
 
   LoopAnalysisManager LAM;
   FunctionAnalysisManager FAM;
static void runNewPMPasses(Module &Mod, TargetMachine *TM, unsigned OptLevel,
   case 2:
     OL = PassBuilder::O2;
     break;
   case 3:
     OL = PassBuilder::O3;
     break;
   }
 
+  if (IsThinLTO)
+    MPM = PB.buildThinLTODefaultPipeline(OL, false /* DebugLogging */);
+  else
     MPM = PB.buildLTODefaultPipeline(OL, false /* DebugLogging */);
   MPM.run(Mod, MAM);
 
   // FIXME (davide): verify the output.
 }
 
 static void runNewPMCustomPasses(Module &Mod, TargetMachine *TM,
                                  std::string PipelineDesc,
                                  std::string AAPipelineDesc,
static void runOldPMPasses(Config &Conf, Module &Mod, TargetMachine *TM,
   else
     PMB.populateLTOPassManager(passes);
   passes.run(Mod);
 }
 
 bool opt(Config &Conf, TargetMachine *TM, unsigned Task, Module &Mod,
          bool IsThinLTO, ModuleSummaryIndex *ExportSummary,
          const ModuleSummaryIndex *ImportSummary) {
-  // There's still no ThinLTO pipeline hooked up in the new pass manager,
-  // once there is one, we can just remove this.
-  if (LTOUseNewPM && IsThinLTO)
-    report_fatal_error("ThinLTO not supported with the new PM yet!");
-
   // FIXME: Plumb the combined index into the new pass manager.
   if (!Conf.OptPipeline.empty())
     runNewPMCustomPasses(Mod, TM, Conf.OptPipeline, Conf.AAPipeline,
                          Conf.DisableVerify);
   else if (LTOUseNewPM)
-    runNewPMPasses(Mod, TM, Conf.OptLevel);
+    runNewPMPasses(Mod, TM, Conf.OptLevel, IsThinLTO);
   else
     runOldPMPasses(Conf, Mod, TM, IsThinLTO, ExportSummary, ImportSummary);
   return !Conf.PostOptModuleHook || Conf.PostOptModuleHook(Task, Mod);
 }
 
 void codegen(Config &Conf, TargetMachine *TM, AddStreamFn AddStream,
              unsigned Task, Module &Mod) {
   if (Conf.PreCodeGenModuleHook && !Conf.PreCodeGenModuleHook(Task, Mod))

llvm/trunk/lib/Passes/PassBuilder.cpp

static cl::opt<bool>
     RunNewGVN("enable-npm-newgvn", cl::init(false),
               cl::Hidden, cl::ZeroOrMore,
               cl::desc("Run NewGVN instead of GVN"));
 
 static cl::opt<bool> EnableGVNHoist(
     "enable-npm-gvn-hoist", cl::init(false), cl::Hidden,
     cl::desc("Enable the GVN hoisting pass for the new PM (default = off)"));
 
-static Regex DefaultAliasRegex("^(default|lto-pre-link|lto)<(O[0123sz])>$");
+static Regex DefaultAliasRegex(
+    "^(default|thinlto-pre-link|thinlto|lto-pre-link|lto)<(O[0123sz])>$");
 
 static bool isOptimizingForSize(PassBuilder::OptimizationLevel Level) {
   switch (Level) {
   case PassBuilder::O0:
   case PassBuilder::O1:
   case PassBuilder::O2:
   case PassBuilder::O3:
     return false;
PassBuilder::buildFunctionSimplificationPipeline(OptimizationLevel Level,
 
   // Rotate Loop - disable header duplication at -Oz
   LPM1.addPass(LoopRotatePass(Level != Oz));
   LPM1.addPass(LICMPass());
   LPM1.addPass(SimpleLoopUnswitchPass());
   LPM2.addPass(IndVarSimplifyPass());
   LPM2.addPass(LoopIdiomRecognizePass());
   LPM2.addPass(LoopDeletionPass());
+  // FIXME: The old pass manager has a hack to disable loop unrolling during
+  // ThinLTO when using sample PGO. Need to either fix it or port some
+  // workaround.
   LPM2.addPass(LoopUnrollPass::createFull(Level));
 
   // We provide the opt remark emitter pass for LICM to use. We only need to do
   // this once as it is immutable.
   FPM.addPass(RequireAnalysisPass<OptimizationRemarkEmitterAnalysis, Function>());
   FPM.addPass(createFunctionToLoopPassAdaptor(std::move(LPM1)));
   FPM.addPass(SimplifyCFGPass());
   FPM.addPass(InstCombinePass());
if (RunProfileGen) {
     MPM.addPass(InstrProfiling(Options));
   }
 
   if (!ProfileUseFile.empty())
     MPM.addPass(PGOInstrumentationUse(ProfileUseFile));
 }
 
 ModulePassManager
-PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
+PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
                                                bool DebugLogging) {
-  assert(Level != O0 && "Must request optimizations for the default pipeline!");
   ModulePassManager MPM(DebugLogging);
 
-  // Force any function attributes we want the rest of the pipeline te observe.
-  MPM.addPass(ForceFunctionAttrsPass());
-
   // Do basic inference of function attributes from known properties of system
   // libraries and other oracles.
   MPM.addPass(InferFunctionAttrsPass());
 
   // Create an early function pass manager to cleanup the output of the
   // frontend.
   FunctionPassManager EarlyFPM(DebugLogging);
   EarlyFPM.addPass(SimplifyCFGPass());
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
 
   // Create a small function pass pipeline to cleanup after all the global
   // optimizations.
   FunctionPassManager GlobalCleanupPM(DebugLogging);
   GlobalCleanupPM.addPass(InstCombinePass());
   GlobalCleanupPM.addPass(SimplifyCFGPass());
   MPM.addPass(createModuleToFunctionPassAdaptor(std::move(GlobalCleanupPM)));
 
-  // Add all the requested passes for PGO Instrumentation, if requested.
+  // Add all the requested passes for PGO, if requested.
   if (PGOOpt) {
     assert(PGOOpt->RunProfileGen || PGOOpt->SamplePGO ||
            !PGOOpt->ProfileUseFile.empty());
     addPGOInstrPasses(MPM, DebugLogging, Level, PGOOpt->RunProfileGen,
                       PGOOpt->ProfileGenFile, PGOOpt->ProfileUseFile);
-  }
 
     // Indirect call promotion that promotes intra-module targes only.
     MPM.addPass(PGOIndirectCallPromotion(false, PGOOpt && PGOOpt->SamplePGO));
+  }
 
   // Require the GlobalsAA analysis for the module so we can query it within
   // the CGSCC pipeline.
   MPM.addPass(RequireAnalysisPass<GlobalsAA, Module>());
 
   // Require the ProfileSummaryAnalysis for the module so we can query it within
   // the inliner pass.
   MPM.addPass(RequireAnalysisPass<ProfileSummaryAnalysis, Module>());
PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
   // to detect when we devirtualize indirect calls and iterate the SCC passes
   // in that case to try and catch knock-on inlining or function attrs
   // opportunities. Then we add it to the module pipeline by walking the SCCs
   // in postorder (or bottom-up).
   MPM.addPass(
       createModuleToPostOrderCGSCCPassAdaptor(createDevirtSCCRepeatedPass(
           std::move(MainCGPipeline), MaxDevirtIterations, DebugLogging)));
 
-  // This ends the canonicalization and simplification phase of the pipeline.
-  // At this point, we expect to have canonical and simple IR which we begin
-  // *optimizing* for efficient execution going forward.
+  return MPM;
+}
+
+ModulePassManager
+PassBuilder::buildModuleOptimizationPipeline(OptimizationLevel Level,
+                                             bool DebugLogging) {
+  ModulePassManager MPM(DebugLogging);
+
+  // Optimize globals now that the module is fully simplified.
+  MPM.addPass(GlobalOptPass());
 
   // Run partial inlining pass to partially inline functions that have
   // large bodies.
   if (RunPartialInlining)
     MPM.addPass(PartialInlinerPass());
 
-  // Eliminate externally available functions now that inlining is over -- we
-  // won't emit these anyways.
+  // 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
+  // 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.
   MPM.addPass(EliminateAvailableExternallyPass());
 
   // 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());
 
   // Re-require GloblasAA here prior to function passes. This is particularly
PassBuilder::buildModuleOptimizationPipeline(OptimizationLevel Level,
   // ordering here.
   MPM.addPass(GlobalDCEPass());
   MPM.addPass(ConstantMergePass());
 
   return MPM;
 }
 
 ModulePassManager
+PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
+                                           bool DebugLogging) {
+  assert(Level != O0 && "Must request optimizations for the default pipeline!");
+
+  ModulePassManager MPM(DebugLogging);
+
+  // Force any function attributes we want the rest of the pipeline to observe.
+  MPM.addPass(ForceFunctionAttrsPass());
+
+  // Add the core simplification pipeline.
+  MPM.addPass(buildModuleSimplificationPipeline(Level, DebugLogging));
+
+  // Now add the optimization pipeline.
+  MPM.addPass(buildModuleOptimizationPipeline(Level, DebugLogging));
+
+  return MPM;
+}
+
+ModulePassManager
+PassBuilder::buildThinLTOPreLinkDefaultPipeline(OptimizationLevel Level,
+                                                bool DebugLogging) {
+  assert(Level != O0 && "Must request optimizations for the default pipeline!");
+
+  ModulePassManager MPM(DebugLogging);
+
+  // Force any function attributes we want the rest of the pipeline to observe.
+  MPM.addPass(ForceFunctionAttrsPass());
+
+  // 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, DebugLogging));
+
+  // 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.
+  if (RunPartialInlining)
+    MPM.addPass(PartialInlinerPass());
+
+  // Reduce the size of the IR as much as possible.
+  MPM.addPass(GlobalOptPass());
+
+  // Rename anon globals to be able to export them in the summary.
+  MPM.addPass(NameAnonGlobalPass());
+
+  return MPM;
+}
+
+ModulePassManager
+PassBuilder::buildThinLTODefaultPipeline(OptimizationLevel Level,
+                                         bool DebugLogging) {
+  // FIXME: The summary index is not hooked in the new pass manager yet.
+  // When it's going to be hooked, enable WholeProgramDevirt and LowerTypeTest
+  // here.
+
+  ModulePassManager MPM(DebugLogging);
+
+  // Force any function attributes we want the rest of the pipeline to observe.
+  MPM.addPass(ForceFunctionAttrsPass());
+
+  // During the ThinLTO backend phase we perform early indirect call promotion
+  // here, before globalopt. Otherwise imported available_externally functions
+  // look unreferenced and are removed.
+  MPM.addPass(PGOIndirectCallPromotion(true /* InLTO */,
+                                       PGOOpt && PGOOpt->SamplePGO &&
+                                           !PGOOpt->ProfileUseFile.empty()));
+
+  // Add the core simplification pipeline.
+  MPM.addPass(buildModuleSimplificationPipeline(Level, DebugLogging));
+
+  // Now add the optimization pipeline.
+  MPM.addPass(buildModuleOptimizationPipeline(Level, DebugLogging));
+
+  return MPM;
+}
+
+ModulePassManager
 PassBuilder::buildLTOPreLinkDefaultPipeline(OptimizationLevel Level,
                                             bool DebugLogging) {
   assert(Level != O0 && "Must request optimizations for the default pipeline!");
   // FIXME: We should use a customized pre-link pipeline!
   return buildPerModuleDefaultPipeline(Level, DebugLogging);
 }
 
 ModulePassManager PassBuilder::buildLTODefaultPipeline(OptimizationLevel Level,
static Optional<int> parseDevirtPassName(StringRef Name) {
   if (!Name.consume_front("devirt<") || !Name.consume_back(">"))
     return None;
   int Count;
   if (Name.getAsInteger(0, Count) || Count <= 0)
     return None;
   return Count;
 }
 
+/// Tests whether a pass name starts with a valid prefix for a default pipeline
+/// alias.
+static bool startsWithDefaultPipelineAliasPrefix(StringRef Name) {
+  return Name.startswith("default") || Name.startswith("thinlto") ||
+         Name.startswith("lto");
+}
+
 static bool isModulePassName(StringRef Name) {
   // Manually handle aliases for pre-configured pipeline fragments.
-  if (Name.startswith("default") || Name.startswith("lto"))
+  if (startsWithDefaultPipelineAliasPrefix(Name))
     return DefaultAliasRegex.match(Name);
 
   // Explicitly handle pass manager names.
   if (Name == "module")
     return true;
   if (Name == "cgscc")
     return true;
   if (Name == "function")
if (auto Count = parseRepeatPassName(Name)) {
       MPM.addPass(createRepeatedPass(*Count, std::move(NestedMPM)));
       return true;
     }
     // Normal passes can't have pipelines.
     return false;
   }
 
   // Manually handle aliases for pre-configured pipeline fragments.
-  if (Name.startswith("default") || Name.startswith("lto")) {
+  if (startsWithDefaultPipelineAliasPrefix(Name)) {
     SmallVector<StringRef, 3> Matches;
     if (!DefaultAliasRegex.match(Name, &Matches))
       return false;
     assert(Matches.size() == 3 && "Must capture two matched strings!");
 
     OptimizationLevel L = StringSwitch<OptimizationLevel>(Matches[2])
         .Case("O0", O0)
         .Case("O1", O1)
         .Case("O2", O2)
         .Case("O3", O3)
         .Case("Os", Os)
         .Case("Oz", Oz);
     if (L == O0)
       // At O0 we do nothing at all!
       return true;
 
     if (Matches[1] == "default") {
       MPM.addPass(buildPerModuleDefaultPipeline(L, DebugLogging));
+    } else if (Matches[1] == "thinlto-pre-link") {
+      MPM.addPass(buildThinLTOPreLinkDefaultPipeline(L, DebugLogging));
+    } else if (Matches[1] == "thinlto") {
+      MPM.addPass(buildThinLTODefaultPipeline(L, DebugLogging));
     } else if (Matches[1] == "lto-pre-link") {
       MPM.addPass(buildLTOPreLinkDefaultPipeline(L, DebugLogging));
     } else {
       assert(Matches[1] == "lto" && "Not one of the matched options!");
       MPM.addPass(buildLTODefaultPipeline(L, DebugLogging));
     }
     return true;
   }

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

 ; RUN: opt -disable-verify -debug-pass-manager \
 ; RUN:     -passes='lto-pre-link<O2>' -S %s 2>&1 \
 ; RUN:     | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2
 
 ; CHECK-O: Starting llvm::Module pass manager run.
 ; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
 ; CHECK-O-NEXT: Starting llvm::Module pass manager run.
 ; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.
 ; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
 ; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Starting llvm::Function pass manager run.
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O-NEXT: Running analysis: TargetIRAnalysis
 ; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
 ; CHECK-O-NEXT: Running pass: SROA
 ; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
 ; CHECK-O-NEXT: Running pass: EarlyCSEPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
 ; CHECK-O-NEXT: Running pass: LowerExpectIntrinsicPass
 ; CHECK-O-NEXT: Finished llvm::Function pass manager run.
 ; CHECK-O-NEXT: Running pass: IPSCCPPass
 ; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PromotePass>
 ; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
 ; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
 ; CHECK-O-NEXT: Starting llvm::Function pass manager run.
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O-NEXT: Finished llvm::Function pass manager run.
-; CHECK-O-NEXT: Running pass: PGOIndirectCallPromotion
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
 ; CHECK-O-NEXT: Running analysis: GlobalsAA
 ; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
 ; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
 ; CHECK-O-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor<{{.*}}LazyCallGraph{{.*}}>
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis

 ; CHECK-O-NEXT: Running pass: DSEPass
 ; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass{{.*}}>
 ; CHECK-O-NEXT: Running pass: ADCEPass
 ; CHECK-O-NEXT: Running analysis: PostDominatorTreeAnalysis
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O-NEXT: Running pass: InstCombinePass
 ; CHECK-O-NEXT: Finished llvm::Function pass manager run.
 ; CHECK-O-NEXT: Finished CGSCC pass manager run.
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.
+; CHECK-O-NEXT: Running pass: GlobalOptPass
 ; CHECK-O-NEXT: Running pass: EliminateAvailableExternallyPass
 ; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
 ; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
 ; CHECK-O-NEXT: Starting llvm::Function pass manager run.
 ; CHECK-O-NEXT: Running pass: Float2IntPass
 ; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopRotatePass
 ; CHECK-O-NEXT: Running pass: LoopDistributePass

 ; CHECK-O-NEXT: Running pass: AlignmentFromAssumptionsPass
 ; CHECK-O-NEXT: Running pass: LoopSinkPass
 ; CHECK-O-NEXT: Running pass: InstSimplifierPass
 ; CHECK-O-NEXT: Running pass: SimplifyCFGPass
 ; CHECK-O-NEXT: Finished llvm::Function pass manager run.
 ; CHECK-O-NEXT: Running pass: GlobalDCEPass
 ; CHECK-O-NEXT: Running pass: ConstantMergePass
 ; CHECK-O-NEXT: Finished llvm::Module pass manager run.
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.
 ; 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/trunk/test/Other/new-pm-thinlto-defaults.ll

+; The IR below was crafted so as:
+; 1) To have a loop, so we create a loop pass manager
+; 2) To be "immutable" in the sense that no pass in the standard
+;    pipeline will modify it.
+; Since no transformations take place, we don't expect any analyses
+; to be invalidated.
+; Any invalidation that shows up here is a bug, unless we started modifying
+; the IR, in which case we need to make it immutable harder.
+;
+; Prelink pipelines:
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto-pre-link<O1>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O1,CHECK-PRELINK-O,CHECK-PRELINK-O1
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto-pre-link<O2>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-PRELINK-O,CHECK-PRELINK-O2
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto-pre-link<O3>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O3,CHECK-PRELINK-O,CHECK-PRELINK-O3
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto-pre-link<Os>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-Os,CHECK-PRELINK-O,CHECK-PRELINK-Os
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto-pre-link<Oz>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-Oz,CHECK-PRELINK-O,CHECK-PRELINK-Oz
+;
+; Postlink pipelines:
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto<O1>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O1,CHECK-POSTLINK-O,CHECK-POSTLINK-O1
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto<O2>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-POSTLINK-O,CHECK-POSTLINK-O2
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto<O3>' -S  %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-O3,CHECK-POSTLINK-O,CHECK-POSTLINK-O3
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto<Os>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-Os,CHECK-POSTLINK-O,CHECK-POSTLINK-Os
+; RUN: opt -disable-verify -debug-pass-manager \
+; RUN:     -passes='thinlto<Oz>' -S %s 2>&1 \
+; RUN:     | FileCheck %s --check-prefixes=CHECK-O,CHECK-Oz,CHECK-POSTLINK-O,CHECK-POSTLINK-Oz
+;
+; CHECK-O: Starting llvm::Module pass manager run.
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.
+; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
+; CHECK-POSTLINK-O-NEXT: Running pass: PGOIndirectCallPromotion
+; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Module pass manager run.
+; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
+; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
+; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
+; CHECK-O-NEXT: Starting llvm::Function pass manager run.
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Running analysis: TargetIRAnalysis
+; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
+; CHECK-O-NEXT: Running pass: SROA
+; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
+; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
+; CHECK-O-NEXT: Running pass: LowerExpectIntrinsicPass
+; CHECK-O-NEXT: Finished llvm::Function pass manager run.
+; CHECK-O-NEXT: Running pass: IPSCCPPass
+; CHECK-O-NEXT: Running pass: GlobalOptPass
+; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PromotePass>
+; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
+; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Function pass manager run.
+; CHECK-O-NEXT: Running pass: InstCombinePass
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Finished llvm::Function pass manager run.
+; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
+; CHECK-O-NEXT: Running analysis: GlobalsAA
+; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
+; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
+; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
+; CHECK-O-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor<{{.*}}LazyCallGraph{{.*}}>
+; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
+; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
+; CHECK-O-NEXT: Starting CGSCC pass manager run.
+; CHECK-O-NEXT: Running pass: InlinerPass
+; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy<{{.*}}LazyCallGraph{{.*}}>
+; CHECK-O-NEXT: Running pass: PostOrderFunctionAttrsPass
+; CHECK-O-NEXT: Running analysis: FunctionAnalysisManagerCGSCCProxy
+; CHECK-O-NEXT: Running analysis: AAManager
+; CHECK-O3-NEXT: Running pass: ArgumentPromotionPass
+; CHECK-O-NEXT: Running pass: CGSCCToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
+; CHECK-O-NEXT: Starting llvm::Function pass manager run.
+; CHECK-O-NEXT: Running pass: SROA
+; CHECK-O-NEXT: Running pass: EarlyCSEPass
+; CHECK-O-NEXT: Running pass: SpeculativeExecutionPass
+; CHECK-O-NEXT: Running pass: JumpThreadingPass
+; CHECK-O-NEXT: Running analysis: LazyValueAnalysis
+; CHECK-O-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Running pass: InstCombinePass
+; CHECK-O1-NEXT: Running pass: LibCallsShrinkWrapPass
+; CHECK-O2-NEXT: Running pass: LibCallsShrinkWrapPass
+; CHECK-O3-NEXT: Running pass: LibCallsShrinkWrapPass
+; CHECK-O-NEXT: Running pass: TailCallElimPass
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Running pass: ReassociatePass
+; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
+; CHECK-O-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis
+; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopStandardAnalysisResults{{.*}}>
+; CHECK-O-NEXT: Running analysis: LoopAnalysis
+; CHECK-O-NEXT: Running analysis: ScalarEvolutionAnalysis
+; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
+; CHECK-O-NEXT: Starting Loop pass manager run.
+; CHECK-O-NEXT: Running pass: LoopRotatePass
+; CHECK-O-NEXT: Running pass: LICM
+; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
+; CHECK-O-NEXT: Running pass: SimpleLoopUnswitchPass
+; CHECK-O-NEXT: Finished Loop pass manager run.
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Running pass: InstCombinePass
+; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopStandardAnalysisResults{{.*}}>
+; CHECK-O-NEXT: Starting Loop pass manager run.
+; CHECK-O-NEXT: Running pass: IndVarSimplifyPass
+; CHECK-O-NEXT: Running pass: LoopIdiomRecognizePass
+; CHECK-O-NEXT: Running pass: LoopDeletionPass
+; CHECK-O-NEXT: Running pass: LoopUnrollPass
+; CHECK-O-NEXT: Finished Loop pass manager run.
+; CHECK-Os-NEXT: Running pass: MergedLoadStoreMotionPass
+; CHECK-Os-NEXT: Running pass: GVN
+; CHECK-Os-NEXT: Running analysis: MemoryDependenceAnalysis
+; CHECK-Oz-NEXT: Running pass: MergedLoadStoreMotionPass
+; CHECK-Oz-NEXT: Running pass: GVN
+; CHECK-Oz-NEXT: Running analysis: MemoryDependenceAnalysis
+; CHECK-O2-NEXT: Running pass: MergedLoadStoreMotionPass
+; CHECK-O2-NEXT: Running pass: GVN
+; CHECK-O2-NEXT: Running analysis: MemoryDependenceAnalysis
+; CHECK-O3-NEXT: Running pass: MergedLoadStoreMotionPass
+; CHECK-O3-NEXT: Running pass: GVN
+; CHECK-O3-NEXT: Running analysis: MemoryDependenceAnalysis
+; CHECK-O-NEXT: Running pass: MemCpyOptPass
+; CHECK-O1-NEXT: Running analysis: MemoryDependenceAnalysis
+; CHECK-O-NEXT: Running pass: SCCPPass
+; CHECK-O-NEXT: Running pass: BDCEPass
+; CHECK-O-NEXT: Running analysis: DemandedBitsAnalysis
+; CHECK-O-NEXT: Running pass: InstCombinePass
+; CHECK-O-NEXT: Running pass: JumpThreadingPass
+; CHECK-O-NEXT: Running pass: CorrelatedValuePropagationPass
+; CHECK-O-NEXT: Running pass: DSEPass
+; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass{{.*}}>
+; CHECK-O-NEXT: Running pass: ADCEPass
+; CHECK-O-NEXT: Running analysis: PostDominatorTreeAnalysis
+; CHECK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-O-NEXT: Running pass: InstCombinePass
+; CHECK-O-NEXT: Finished llvm::Function pass manager run.
+; CHECK-O-NEXT: Finished CGSCC pass manager run.
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.
+; CHECK-PRELINK-O-NEXT: Running pass: GlobalOptPass
+; CHECK-PRELINK-O-NEXT: Running pass: NameAnonGlobalPass
+; CHECK-POSTLINK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
+; CHECK-POSTLINK-O-NEXT: Starting llvm::Module pass manager run.
+; CHECK-POSTLINK-O-NEXT: Running pass: GlobalOptPass
+; CHECK-POSTLINK-O-NEXT: Running pass: EliminateAvailableExternallyPass
+; CHECK-POSTLINK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
+; CHECK-POSTLINK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
+; CHECK-POSTLINK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
+; CHECK-POSTLINK-O-NEXT: Starting llvm::Function pass manager run.
+; CHECK-POSTLINK-O-NEXT: Running pass: Float2IntPass
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopRotatePass
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopDistributePass
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopVectorizePass
+; CHECK-POSTLINK-O-NEXT: Running analysis: BlockFrequencyAnalysis
+; CHECK-POSTLINK-O-NEXT: Running analysis: BranchProbabilityAnalysis
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopLoadEliminationPass
+; CHECK-POSTLINK-O-NEXT: Running analysis: LoopAccessAnalysis
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass
+; CHECK-POSTLINK-O-NEXT: Running pass: SLPVectorizerPass
+; CHECK-POSTLINK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopUnrollPass
+; CHECK-POSTLINK-O-NEXT: Running pass: InstCombinePass
+; CHECK-POSTLINK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
+; CHECK-POSTLINK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass
+; CHECK-POSTLINK-O-NEXT: Running pass: AlignmentFromAssumptionsPass
+; CHECK-POSTLINK-O-NEXT: Running pass: LoopSinkPass
+; CHECK-POSTLINK-O-NEXT: Running pass: InstSimplifierPass
+; CHECK-POSTLINK-O-NEXT: Running pass: SimplifyCFGPass
+; CHECK-POSTLINK-O-NEXT: Finished llvm::Function pass manager run.
+; CHECK-POSTLINK-O-NEXT: Running pass: GlobalDCEPass
+; CHECK-POSTLINK-O-NEXT: Running pass: ConstantMergePass
+; CHECK-POSTLINK-O-NEXT: Finished llvm::Module pass manager run.
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.
+; 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 ]
+; CHECK-O-NEXT:   %iv.next = add i32 %iv, 1
+; CHECK-O-NEXT:   tail call void @bar()
+; CHECK-O-NEXT:   %cmp = icmp eq i32 %iv, %n
+; CHECK-O-NEXT:   br i1 %cmp, label %exit, label %loop
+; CHECK-O:      exit:
+; CHECK-O-NEXT:   ret void
+; CHECK-O-NEXT: }
+;
+; CHECK-O-NEXT: Finished llvm::Module pass manager run.
+
+declare void @bar() local_unnamed_addr
+
+define void @foo(i32 %n) local_unnamed_addr {
+entry:
+  br label %loop
+loop:
+  %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
+  %iv.next = add i32 %iv, 1
+  tail call void @bar()
+  %cmp = icmp eq i32 %iv, %n
+  br i1 %cmp, label %exit, label %loop
+exit:
+  ret void
+}

llvm/trunk/test/ThinLTO/X86/error-newpm.ll

-; RUN: opt -module-summary %s -o %t1.bc
-; RUN: not llvm-lto2 run %t1.bc -o %t.o \
-; RUN:     -r=%t1.bc,_tinkywinky,pxl \
-; RUN:     -lto-use-new-pm 2>&1 | FileCheck %s
-
-; CHECK: ThinLTO not supported with the new PM yet!
-
-target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
-target triple = "x86_64-apple-macosx10.11.0"
-
-define void @tinkywinky() {
-    ret void
-}

llvm/trunk/test/ThinLTO/X86/newpm-basic.ll

+; RUN: opt -module-summary %s -o %t1.bc
+; RUN: llvm-lto2 run %t1.bc -o %t.o \
+; RUN:     -r=%t1.bc,_tinkywinky,pxl \
+; RUN:     -lto-use-new-pm
+
+target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-apple-macosx10.11.0"
+
+define void @tinkywinky() {
+    ret void
+}