[llvm] r304407 - [PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.
Sean Silva via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 1 18:50:29 PDT 2017
On Thu, Jun 1, 2017 at 5:48 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> On Thu, Jun 1, 2017 at 11:20 AM Sean Silva <chisophugis at gmail.com> wrote:
>
>> On Thu, Jun 1, 2017 at 4:39 AM, Chandler Carruth via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>>> Author: chandlerc
>>> Date: Thu Jun 1 06:39:39 2017
>>> New Revision: 304407
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=304407&view=rev
>>> Log:
>>> [PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.
>>>
>>> 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 run 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 the RPO function
>>> attr inference. The RPO inference won't infer anything terribly
>>> meaningful pre-link (recursiveness?) so it didn't make a lot of
>>> sense. But if the placement of 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.
>>>
>>> I added support for parsing 'thinlto' and 'thinlto-pre-link' names in
>>> pass pipelines to make it easy to test these routines and play with them
>>> in larger pipelines. I also added a really basic manifest of passes test
>>> that will show exactly how the pipelines behave and work as well as
>>> making updates to them clear.
>>>
>>> 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.
>>>
>>> Differential Revision: https://reviews.llvm.org/D33540
>>>
>>> Added:
>>> llvm/trunk/test/Other/new-pm-thinlto-defaults.ll
>>> - copied, changed from r304404, llvm/trunk/test/Other/new-pm-
>>> defaults.ll
>>> llvm/trunk/test/ThinLTO/X86/newpm-basic.ll
>>> - copied, changed from r304404, llvm/trunk/test/ThinLTO/X86/
>>> error-newpm.ll
>>> Removed:
>>> llvm/trunk/test/ThinLTO/X86/error-newpm.ll
>>> Modified:
>>> llvm/trunk/include/llvm/Passes/PassBuilder.h
>>> llvm/trunk/lib/LTO/LTOBackend.cpp
>>> llvm/trunk/lib/Passes/PassBuilder.cpp
>>> llvm/trunk/test/Other/new-pm-defaults.ll
>>>
>>> Modified: llvm/trunk/include/llvm/Passes/PassBuilder.h
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/
>>> llvm/Passes/PassBuilder.h?rev=304407&r1=304406&r2=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/include/llvm/Passes/PassBuilder.h (original)
>>> +++ llvm/trunk/include/llvm/Passes/PassBuilder.h Thu Jun 1 06:39:39
>>> 2017
>>> @@ -192,6 +192,39 @@ public:
>>> 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
>>> @@ -206,6 +239,36 @@ public:
>>> 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.
>>>
>>
>> I think this name `pre-link` is probably as good as we can come up with
>> for the moment, but it might be good just for clarity and explicitness to
>> say something like "For example, this is the optimization pipeline that the
>> per-TU clang invocation would run with -flto=thin".
>>
>
> Can you think of a way to explain this without referencing Clang? It feels
> bad to explain LLVM stuff in terms of Clang stuff. (I tried a few things
> and they all ended up completely redundant or completely confusing...)
>
I agree with the sentiment in general, but prefaced with `For example` I
think it is reasonable. I think this is especially true since some (most?)
of our documentation widely disseminating understanding of ThinLTO does
describe it from the point of view of a general C/C++ build workflow (e.g.
https://www.youtube.com/watch?v=9OIEZAj243g). That was good choice I think
because C/C++ build workflows will be something that people hacking
on/using LLVM will be familiar with regardless of what their intended
frontend is.
In fact, it may be useful to explicitly call out in the docs how our new
terminology correlates with the terminology used at e.g.
https://youtu.be/9OIEZAj243g?t=15m52s
-- Sean Silva
>
>
>>
>>
>>
>>> + ///
>>> + /// 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.
>>>
>>
>> Quick question to verify my understanding: with the current design for
>> coroutines, when optimizing, we would actually prefer to do the
>> semantically necessary coroutine lowering while running one of these
>> pipelines that you have marked as "If frontends require some
>> transformations for semantic reasons, they should explicitly build them",
>> essentially being an annoying exception to that (i.e. the frontend would
>> *not* manually run the coroutine lowering passes separately first in that
>> case).
>>
>> I realize this may be a can of worms that hasn't been fully figured out
>> now, so I'm totally fine with a "that's still in the air" type answer. E.g.
>> we presumably want to do coroutine lowering in the very last inlining run
>> that we do (i.e. post-thin-link), so we would need to always assume that
>> our input bitcode hasn't necessarily had the coroutine lowering run on it,
>> so the post-thin-link optimization pipeline would always need to run
>> coroutine lowering?
>>
>
> I mean, I think this is still a bit up in the air, but I have a theory
> about how this should eventually end up working.
>
> I think we can provide extension points that are reasonably used to inject
> semantically significant passes into the pipeline. Philip has a patch that
> is coming along nicely here. I'm hoping it will address the Sanitizers' use
> case off the bat, and that we can craft any other extension points
> necessary for semantically significant passes.
>
> That said, part of the solution for coroutines may end up being adjusting
> how the lowering works to relax some of the requirements. But I think it is
> totally fine to live with some uncertainty and "this isn't supposed to work
> that way"-ness while they're still very experimental and we're still
> figuring the best process out.
>
>
>
>
>> -- Sean Silva
>>
>>
>>> + ModulePassManager buildThinLTODefaultPipeline(OptimizationLevel
>>> Level,
>>> + bool DebugLogging =
>>> false);
>>> +
>>> /// Build a pre-link, LTO-targeting default optimization pipeline to
>>> a pass
>>> /// manager.
>>> ///
>>>
>>> Modified: llvm/trunk/lib/LTO/LTOBackend.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/LTO/
>>> LTOBackend.cpp?rev=304407&r1=304406&r2=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/lib/LTO/LTOBackend.cpp (original)
>>> +++ llvm/trunk/lib/LTO/LTOBackend.cpp Thu Jun 1 06:39:39 2017
>>> @@ -136,7 +136,8 @@ createTargetMachine(Config &Conf, const
>>> 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;
>>>
>>> @@ -180,7 +181,10 @@ static void runNewPMPasses(Module &Mod,
>>> break;
>>> }
>>>
>>> - MPM = PB.buildLTODefaultPipeline(OL, false /* DebugLogging */);
>>> + if (IsThinLTO)
>>> + MPM = PB.buildThinLTODefaultPipeline(OL, false /* DebugLogging */);
>>> + else
>>> + MPM = PB.buildLTODefaultPipeline(OL, false /* DebugLogging */);
>>> MPM.run(Mod, MAM);
>>>
>>> // FIXME (davide): verify the output.
>>> @@ -258,17 +262,12 @@ static void runOldPMPasses(Config &Conf,
>>> 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);
>>>
>>> Modified: llvm/trunk/lib/Passes/PassBuilder.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Passes/
>>> PassBuilder.cpp?rev=304407&r1=304406&r2=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/lib/Passes/PassBuilder.cpp (original)
>>> +++ llvm/trunk/lib/Passes/PassBuilder.cpp Thu Jun 1 06:39:39 2017
>>> @@ -164,7 +164,8 @@ 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) {
>>> @@ -345,6 +346,9 @@ PassBuilder::buildFunctionSimplification
>>> 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
>>> @@ -454,14 +458,10 @@ static void addPGOInstrPasses(ModulePass
>>> }
>>>
>>> ModulePassManager
>>> -PassBuilder::buildPerModuleDefaultPipeline(OptimizationLevel Level,
>>> - bool DebugLogging) {
>>> - assert(Level != O0 && "Must request optimizations for the default
>>> pipeline!");
>>> +PassBuilder::buildModuleSimplificationPipeline(OptimizationLevel Level,
>>> + bool DebugLogging) {
>>> 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());
>>> @@ -504,16 +504,16 @@ PassBuilder::buildPerModuleDefaultPipeli
>>> GlobalCleanupPM.addPass(SimplifyCFGPass());
>>> MPM.addPass(createModuleToFunctionPassAdap
>>> tor(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));
>>> + // 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.
>>> @@ -562,17 +562,30 @@ PassBuilder::buildPerModuleDefaultPipeli
>>> 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
>>> @@ -671,6 +684,87 @@ PassBuilder::buildPerModuleDefaultPipeli
>>> }
>>>
>>> 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!");
>>> @@ -893,9 +987,16 @@ static Optional<int> parseDevirtPassName
>>> 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.
>>> @@ -1090,7 +1191,7 @@ bool PassBuilder::parseModulePass(Module
>>> }
>>>
>>> // 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;
>>> @@ -1109,6 +1210,10 @@ bool PassBuilder::parseModulePass(Module
>>>
>>> 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 {
>>>
>>> Modified: llvm/trunk/test/Other/new-pm-defaults.ll
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Other/
>>> new-pm-defaults.ll?rev=304407&r1=304406&r2=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/test/Other/new-pm-defaults.ll (original)
>>> +++ llvm/trunk/test/Other/new-pm-defaults.ll Thu Jun 1 06:39:39 2017
>>> @@ -30,6 +30,8 @@
>>> ; 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{{.*}}>
>>> @@ -53,7 +55,6 @@
>>> ; 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
>>> @@ -134,6 +135,10 @@
>>> ; 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
>>> @@ -163,6 +168,7 @@
>>> ; 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.
>>>
>>> Copied: llvm/trunk/test/Other/new-pm-thinlto-defaults.ll (from r304404,
>>> llvm/trunk/test/Other/new-pm-defaults.ll)
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Other/
>>> new-pm-thinlto-defaults.ll?p2=llvm/trunk/test/Other/new-pm-
>>> thinlto-defaults.ll&p1=llvm/trunk/test/Other/new-pm-
>>> defaults.ll&r1=304404&r2=304407&rev=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/test/Other/new-pm-defaults.ll (original)
>>> +++ llvm/trunk/test/Other/new-pm-thinlto-defaults.ll Thu Jun 1
>>> 06:39:39 2017
>>> @@ -6,30 +6,48 @@
>>> ; 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='default<O1>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O1
>>> +; 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='default<O2>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2
>>> +; 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='default<O3>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3
>>> +; 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='default<Os>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Os
>>> +; 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='default<Oz>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Oz
>>> +; 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='lto-pre-link<O2>' -S %s 2>&1 \
>>> -; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2
>>> -
>>> +; 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{{.*}}>
>>> @@ -53,7 +71,6 @@
>>> ; 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
>>> @@ -134,37 +151,44 @@
>>> ; 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: 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: LoopVectorizePass
>>> -; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis
>>> -; CHECK-O-NEXT: Running analysis: BranchProbabilityAnalysis
>>> -; CHECK-O-NEXT: Running pass: LoopLoadEliminationPass
>>> -; CHECK-O-NEXT: Running analysis: LoopAccessAnalysis
>>> -; CHECK-O-NEXT: Running pass: InstCombinePass
>>> -; CHECK-O-NEXT: Running pass: SLPVectorizerPass
>>> -; CHECK-O-NEXT: Running pass: SimplifyCFGPass
>>> -; CHECK-O-NEXT: Running pass: InstCombinePass
>>> -; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*
>>> }}LoopUnrollPass
>>> -; CHECK-O-NEXT: Running pass: InstCombinePass
>>> -; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}
>>> OptimizationRemarkEmitterAnalysis
>>> -; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass
>>> -; 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-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: ReversePostOrderFunctionAttrsP
>>> ass
>>> +; 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:
>>>
>>> Removed: llvm/trunk/test/ThinLTO/X86/error-newpm.ll
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/
>>> ThinLTO/X86/error-newpm.ll?rev=304406&view=auto
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/test/ThinLTO/X86/error-newpm.ll (original)
>>> +++ llvm/trunk/test/ThinLTO/X86/error-newpm.ll (removed)
>>> @@ -1,13 +0,0 @@
>>> -; 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
>>> -}
>>>
>>> Copied: llvm/trunk/test/ThinLTO/X86/newpm-basic.ll (from r304404,
>>> llvm/trunk/test/ThinLTO/X86/error-newpm.ll)
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/
>>> ThinLTO/X86/newpm-basic.ll?p2=llvm/trunk/test/ThinLTO/X86/
>>> newpm-basic.ll&p1=llvm/trunk/test/ThinLTO/X86/error-newpm.
>>> ll&r1=304404&r2=304407&rev=304407&view=diff
>>> ============================================================
>>> ==================
>>> --- llvm/trunk/test/ThinLTO/X86/error-newpm.ll (original)
>>> +++ llvm/trunk/test/ThinLTO/X86/newpm-basic.ll Thu Jun 1 06:39:39 2017
>>> @@ -1,9 +1,7 @@
>>> ; RUN: opt -module-summary %s -o %t1.bc
>>> -; RUN: not llvm-lto2 run %t1.bc -o %t.o \
>>> +; RUN: 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!
>>> +; 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"
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170601/6a0e846c/attachment-0001.html>
More information about the llvm-commits
mailing list