2015-03-07 17:02:36 +08:00
|
|
|
//===- Parsing, selection, and construction of pass pipelines -------------===//
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
/// \file
|
|
|
|
///
|
2015-03-07 17:02:36 +08:00
|
|
|
/// This file provides the implementation of the PassBuilder based on our
|
|
|
|
/// static pass registry as well as related functionality. It also provides
|
|
|
|
/// helpers to aid in analyzing, debugging, and testing passes and pass
|
|
|
|
/// pipelines.
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
///
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
#include "llvm/Passes/PassBuilder.h"
|
2016-02-29 06:16:03 +08:00
|
|
|
#include "llvm/ADT/StringSwitch.h"
|
2016-02-14 07:32:00 +08:00
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
2016-02-20 11:46:03 +08:00
|
|
|
#include "llvm/Analysis/AliasAnalysisEvaluator.h"
|
2016-12-19 16:22:17 +08:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2016-02-14 07:46:24 +08:00
|
|
|
#include "llvm/Analysis/BasicAliasAnalysis.h"
|
2016-05-06 05:13:27 +08:00
|
|
|
#include "llvm/Analysis/BlockFrequencyInfo.h"
|
|
|
|
#include "llvm/Analysis/BlockFrequencyInfoImpl.h"
|
2016-05-05 10:59:57 +08:00
|
|
|
#include "llvm/Analysis/BranchProbabilityInfo.h"
|
2016-09-17 00:56:30 +08:00
|
|
|
#include "llvm/Analysis/CFGPrinter.h"
|
2016-07-06 08:26:41 +08:00
|
|
|
#include "llvm/Analysis/CFLAndersAliasAnalysis.h"
|
|
|
|
#include "llvm/Analysis/CFLSteensAliasAnalysis.h"
|
2014-04-21 19:12:00 +08:00
|
|
|
#include "llvm/Analysis/CGSCCPassManager.h"
|
2016-03-10 19:24:11 +08:00
|
|
|
#include "llvm/Analysis/CallGraph.h"
|
2016-04-19 07:55:01 +08:00
|
|
|
#include "llvm/Analysis/DemandedBits.h"
|
2016-05-13 06:19:39 +08:00
|
|
|
#include "llvm/Analysis/DependenceAnalysis.h"
|
2016-02-26 01:54:15 +08:00
|
|
|
#include "llvm/Analysis/DominanceFrontier.h"
|
2016-03-11 17:15:11 +08:00
|
|
|
#include "llvm/Analysis/GlobalsModRef.h"
|
2016-07-17 06:51:33 +08:00
|
|
|
#include "llvm/Analysis/IVUsers.h"
|
2014-02-06 12:37:03 +08:00
|
|
|
#include "llvm/Analysis/LazyCallGraph.h"
|
2016-06-14 06:01:25 +08:00
|
|
|
#include "llvm/Analysis/LazyValueInfo.h"
|
2016-07-03 05:18:40 +08:00
|
|
|
#include "llvm/Analysis/LoopAccessAnalysis.h"
|
2015-01-20 18:58:50 +08:00
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
2016-03-10 08:55:30 +08:00
|
|
|
#include "llvm/Analysis/MemoryDependenceAnalysis.h"
|
2016-08-12 21:53:02 +08:00
|
|
|
#include "llvm/Analysis/ModuleSummaryAnalysis.h"
|
2016-07-19 00:29:21 +08:00
|
|
|
#include "llvm/Analysis/OptimizationDiagnosticInfo.h"
|
2016-02-26 01:54:07 +08:00
|
|
|
#include "llvm/Analysis/PostDominators.h"
|
2016-06-04 06:54:26 +08:00
|
|
|
#include "llvm/Analysis/ProfileSummaryInfo.h"
|
2016-02-26 01:54:25 +08:00
|
|
|
#include "llvm/Analysis/RegionInfo.h"
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
#include "llvm/Analysis/ScalarEvolution.h"
|
2016-02-20 12:01:45 +08:00
|
|
|
#include "llvm/Analysis/ScalarEvolutionAliasAnalysis.h"
|
2016-02-20 12:03:06 +08:00
|
|
|
#include "llvm/Analysis/ScopedNoAliasAA.h"
|
2015-01-15 19:39:46 +08:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2015-02-01 18:11:22 +08:00
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2016-02-20 12:04:52 +08:00
|
|
|
#include "llvm/Analysis/TypeBasedAliasAnalysis.h"
|
2016-06-25 04:13:42 +08:00
|
|
|
#include "llvm/CodeGen/PreISelIntrinsicLowering.h"
|
2016-07-08 11:32:49 +08:00
|
|
|
#include "llvm/CodeGen/UnreachableBlockElim.h"
|
2015-01-14 18:19:28 +08:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2014-01-12 20:15:39 +08:00
|
|
|
#include "llvm/IR/IRPrintingPasses.h"
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
#include "llvm/IR/PassManager.h"
|
2014-01-20 19:34:08 +08:00
|
|
|
#include "llvm/IR/Verifier.h"
|
2014-01-12 20:15:39 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2016-02-29 06:16:03 +08:00
|
|
|
#include "llvm/Support/Regex.h"
|
2015-02-01 18:11:22 +08:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2016-06-05 13:12:23 +08:00
|
|
|
#include "llvm/Transforms/GCOVProfiler.h"
|
[PM] Port the always inliner to the new pass manager in a much more
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
llvm-svn: 278896
2016-08-17 10:56:20 +08:00
|
|
|
#include "llvm/Transforms/IPO/AlwaysInliner.h"
|
2016-05-05 08:51:09 +08:00
|
|
|
#include "llvm/Transforms/IPO/ConstantMerge.h"
|
2016-07-09 11:25:35 +08:00
|
|
|
#include "llvm/Transforms/IPO/CrossDSOCFI.h"
|
2016-06-12 17:16:39 +08:00
|
|
|
#include "llvm/Transforms/IPO/DeadArgumentElimination.h"
|
2016-05-05 10:37:32 +08:00
|
|
|
#include "llvm/Transforms/IPO/ElimAvailExtern.h"
|
2015-12-27 16:13:45 +08:00
|
|
|
#include "llvm/Transforms/IPO/ForceFunctionAttrs.h"
|
2016-02-18 19:03:11 +08:00
|
|
|
#include "llvm/Transforms/IPO/FunctionAttrs.h"
|
2016-07-19 05:22:24 +08:00
|
|
|
#include "llvm/Transforms/IPO/FunctionImport.h"
|
2016-05-04 03:39:15 +08:00
|
|
|
#include "llvm/Transforms/IPO/GlobalDCE.h"
|
2016-04-26 08:28:01 +08:00
|
|
|
#include "llvm/Transforms/IPO/GlobalOpt.h"
|
2016-11-21 08:28:23 +08:00
|
|
|
#include "llvm/Transforms/IPO/GlobalSplit.h"
|
2015-12-27 16:41:34 +08:00
|
|
|
#include "llvm/Transforms/IPO/InferFunctionAttrs.h"
|
2016-04-27 04:15:52 +08:00
|
|
|
#include "llvm/Transforms/IPO/Internalize.h"
|
2016-07-12 02:10:06 +08:00
|
|
|
#include "llvm/Transforms/IPO/LowerTypeTests.h"
|
2016-06-28 00:50:18 +08:00
|
|
|
#include "llvm/Transforms/IPO/PartialInlining.h"
|
2016-05-06 05:05:36 +08:00
|
|
|
#include "llvm/Transforms/IPO/SCCP.h"
|
2015-10-31 07:28:12 +08:00
|
|
|
#include "llvm/Transforms/IPO/StripDeadPrototypes.h"
|
2016-06-15 05:44:19 +08:00
|
|
|
#include "llvm/Transforms/IPO/WholeProgramDevirt.h"
|
2015-12-27 16:13:45 +08:00
|
|
|
#include "llvm/Transforms/InstCombine/InstCombine.h"
|
2016-04-19 01:47:38 +08:00
|
|
|
#include "llvm/Transforms/InstrProfiling.h"
|
2016-05-06 13:49:19 +08:00
|
|
|
#include "llvm/Transforms/PGOInstrumentation.h"
|
2016-05-28 07:20:16 +08:00
|
|
|
#include "llvm/Transforms/SampleProfile.h"
|
2015-10-31 07:13:18 +08:00
|
|
|
#include "llvm/Transforms/Scalar/ADCE.h"
|
2016-06-15 14:18:01 +08:00
|
|
|
#include "llvm/Transforms/Scalar/AlignmentFromAssumptions.h"
|
2016-05-25 09:57:04 +08:00
|
|
|
#include "llvm/Transforms/Scalar/BDCE.h"
|
2016-07-19 00:29:17 +08:00
|
|
|
#include "llvm/Transforms/Scalar/ConstantHoisting.h"
|
2016-07-07 07:26:29 +08:00
|
|
|
#include "llvm/Transforms/Scalar/CorrelatedValuePropagation.h"
|
2016-04-23 03:40:41 +08:00
|
|
|
#include "llvm/Transforms/Scalar/DCE.h"
|
2016-05-18 05:38:13 +08:00
|
|
|
#include "llvm/Transforms/Scalar/DeadStoreElimination.h"
|
2015-02-01 18:51:23 +08:00
|
|
|
#include "llvm/Transforms/Scalar/EarlyCSE.h"
|
2016-06-25 07:32:02 +08:00
|
|
|
#include "llvm/Transforms/Scalar/Float2Int.h"
|
2016-06-04 06:54:26 +08:00
|
|
|
#include "llvm/Transforms/Scalar/GVN.h"
|
2016-06-14 08:49:23 +08:00
|
|
|
#include "llvm/Transforms/Scalar/GuardWidening.h"
|
2016-06-06 02:01:19 +08:00
|
|
|
#include "llvm/Transforms/Scalar/IndVarSimplify.h"
|
2016-06-14 08:51:09 +08:00
|
|
|
#include "llvm/Transforms/Scalar/JumpThreading.h"
|
2016-07-13 06:42:24 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LICM.h"
|
2016-08-13 12:11:27 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopDataPrefetch.h"
|
2016-07-15 02:28:29 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopDeletion.h"
|
2016-07-19 00:29:27 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopDistribute.h"
|
2016-07-13 02:45:51 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopIdiomRecognize.h"
|
2016-07-16 00:42:11 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopInstSimplify.h"
|
2016-05-04 06:02:31 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopRotation.h"
|
2016-05-04 05:47:32 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopSimplifyCFG.h"
|
2016-07-19 05:41:50 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopStrengthReduce.h"
|
2016-07-20 07:54:23 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LoopUnrollPass.h"
|
2016-05-14 06:52:35 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LowerAtomic.h"
|
2015-01-24 19:13:02 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LowerExpectIntrinsic.h"
|
2016-07-29 06:08:41 +08:00
|
|
|
#include "llvm/Transforms/Scalar/LowerGuardIntrinsic.h"
|
2016-06-14 10:44:55 +08:00
|
|
|
#include "llvm/Transforms/Scalar/MemCpyOptimizer.h"
|
2016-06-18 03:10:09 +08:00
|
|
|
#include "llvm/Transforms/Scalar/MergedLoadStoreMotion.h"
|
2016-07-22 06:28:52 +08:00
|
|
|
#include "llvm/Transforms/Scalar/NaryReassociate.h"
|
2016-05-26 07:38:53 +08:00
|
|
|
#include "llvm/Transforms/Scalar/PartiallyInlineLibCalls.h"
|
2016-04-27 07:39:29 +08:00
|
|
|
#include "llvm/Transforms/Scalar/Reassociate.h"
|
2016-05-18 23:18:25 +08:00
|
|
|
#include "llvm/Transforms/Scalar/SCCP.h"
|
2015-09-12 17:09:14 +08:00
|
|
|
#include "llvm/Transforms/Scalar/SROA.h"
|
2015-12-27 16:13:45 +08:00
|
|
|
#include "llvm/Transforms/Scalar/SimplifyCFG.h"
|
2016-04-23 03:54:10 +08:00
|
|
|
#include "llvm/Transforms/Scalar/Sink.h"
|
2016-08-02 05:48:33 +08:00
|
|
|
#include "llvm/Transforms/Scalar/SpeculativeExecution.h"
|
2016-07-07 07:48:41 +08:00
|
|
|
#include "llvm/Transforms/Scalar/TailRecursionElimination.h"
|
2016-06-16 05:51:30 +08:00
|
|
|
#include "llvm/Transforms/Utils/AddDiscriminators.h"
|
2016-07-23 02:04:25 +08:00
|
|
|
#include "llvm/Transforms/Utils/BreakCriticalEdges.h"
|
2016-06-10 03:44:46 +08:00
|
|
|
#include "llvm/Transforms/Utils/LCSSA.h"
|
Conditionally eliminate library calls where the result value is not used
Summary:
This pass shrink-wraps a condition to some library calls where the call
result is not used. For example:
sqrt(val);
is transformed to
if (val < 0)
sqrt(val);
Even if the result of library call is not being used, the compiler cannot
safely delete the call because the function can set errno on error
conditions.
Note in many functions, the error condition solely depends on the incoming
parameter. In this optimization, we can generate the condition can lead to
the errno to shrink-wrap the call. Since the chances of hitting the error
condition is low, the runtime call is effectively eliminated.
These partially dead calls are usually results of C++ abstraction penalty
exposed by inlining. This optimization hits 108 times in 19 C/C++ programs
in SPEC2006.
Reviewers: hfinkel, mehdi_amini, davidxl
Subscribers: modocache, mgorny, mehdi_amini, xur, llvm-commits, beanz
Differential Revision: https://reviews.llvm.org/D24414
llvm-svn: 284542
2016-10-19 05:36:27 +08:00
|
|
|
#include "llvm/Transforms/Utils/LibCallsShrinkWrap.h"
|
2016-07-09 11:03:01 +08:00
|
|
|
#include "llvm/Transforms/Utils/LoopSimplify.h"
|
2016-08-13 01:28:27 +08:00
|
|
|
#include "llvm/Transforms/Utils/LowerInvoke.h"
|
2016-06-14 11:22:22 +08:00
|
|
|
#include "llvm/Transforms/Utils/Mem2Reg.h"
|
2016-06-02 05:30:40 +08:00
|
|
|
#include "llvm/Transforms/Utils/MemorySSA.h"
|
2016-09-17 00:56:30 +08:00
|
|
|
#include "llvm/Transforms/Utils/NameAnonGlobals.h"
|
2016-07-08 05:14:36 +08:00
|
|
|
#include "llvm/Transforms/Utils/SimplifyInstructions.h"
|
2016-07-26 04:52:00 +08:00
|
|
|
#include "llvm/Transforms/Utils/SymbolRewriter.h"
|
2016-07-10 06:56:50 +08:00
|
|
|
#include "llvm/Transforms/Vectorize/LoopVectorize.h"
|
2016-07-09 11:11:29 +08:00
|
|
|
#include "llvm/Transforms/Vectorize/SLPVectorizer.h"
|
2016-06-14 11:22:22 +08:00
|
|
|
|
2016-02-26 20:17:54 +08:00
|
|
|
#include <type_traits>
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2016-02-29 06:16:03 +08:00
|
|
|
static Regex DefaultAliasRegex("^(default|lto-pre-link|lto)<(O[0123sz])>$");
|
|
|
|
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
namespace {
|
|
|
|
|
2014-01-12 17:34:22 +08:00
|
|
|
/// \brief No-op module pass which does nothing.
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
struct NoOpModulePass {
|
2016-08-09 08:28:38 +08:00
|
|
|
PreservedAnalyses run(Module &M, ModuleAnalysisManager &) {
|
2016-06-17 08:11:01 +08:00
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
2014-01-11 19:52:05 +08:00
|
|
|
static StringRef name() { return "NoOpModulePass"; }
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
};
|
|
|
|
|
2015-01-06 10:50:06 +08:00
|
|
|
/// \brief No-op module analysis.
|
2016-03-11 18:33:22 +08:00
|
|
|
class NoOpModuleAnalysis : public AnalysisInfoMixin<NoOpModuleAnalysis> {
|
|
|
|
friend AnalysisInfoMixin<NoOpModuleAnalysis>;
|
2016-11-24 01:53:26 +08:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
|
|
|
public:
|
2015-01-06 10:50:06 +08:00
|
|
|
struct Result {};
|
2016-08-09 08:28:38 +08:00
|
|
|
Result run(Module &, ModuleAnalysisManager &) { return Result(); }
|
2015-01-06 10:50:06 +08:00
|
|
|
static StringRef name() { return "NoOpModuleAnalysis"; }
|
|
|
|
};
|
|
|
|
|
2014-04-21 19:12:00 +08:00
|
|
|
/// \brief No-op CGSCC pass which does nothing.
|
|
|
|
struct NoOpCGSCCPass {
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
PreservedAnalyses run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &,
|
|
|
|
LazyCallGraph &, CGSCCUpdateResult &UR) {
|
2014-04-21 19:12:00 +08:00
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
|
|
|
static StringRef name() { return "NoOpCGSCCPass"; }
|
|
|
|
};
|
|
|
|
|
2015-01-06 10:50:06 +08:00
|
|
|
/// \brief No-op CGSCC analysis.
|
2016-03-11 18:33:22 +08:00
|
|
|
class NoOpCGSCCAnalysis : public AnalysisInfoMixin<NoOpCGSCCAnalysis> {
|
|
|
|
friend AnalysisInfoMixin<NoOpCGSCCAnalysis>;
|
2016-11-24 01:53:26 +08:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
|
|
|
public:
|
2015-01-06 10:50:06 +08:00
|
|
|
struct Result {};
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
Result run(LazyCallGraph::SCC &, CGSCCAnalysisManager &, LazyCallGraph &G) {
|
2016-06-17 08:11:01 +08:00
|
|
|
return Result();
|
|
|
|
}
|
2015-01-06 10:50:06 +08:00
|
|
|
static StringRef name() { return "NoOpCGSCCAnalysis"; }
|
|
|
|
};
|
|
|
|
|
2014-01-12 17:34:22 +08:00
|
|
|
/// \brief No-op function pass which does nothing.
|
|
|
|
struct NoOpFunctionPass {
|
2016-08-09 08:28:15 +08:00
|
|
|
PreservedAnalyses run(Function &F, FunctionAnalysisManager &) {
|
2016-06-17 08:11:01 +08:00
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
2014-01-12 17:34:22 +08:00
|
|
|
static StringRef name() { return "NoOpFunctionPass"; }
|
|
|
|
};
|
|
|
|
|
2015-01-06 10:50:06 +08:00
|
|
|
/// \brief No-op function analysis.
|
2016-03-11 18:33:22 +08:00
|
|
|
class NoOpFunctionAnalysis : public AnalysisInfoMixin<NoOpFunctionAnalysis> {
|
|
|
|
friend AnalysisInfoMixin<NoOpFunctionAnalysis>;
|
2016-11-24 01:53:26 +08:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
|
|
|
public:
|
2015-01-06 10:50:06 +08:00
|
|
|
struct Result {};
|
2016-08-09 08:28:15 +08:00
|
|
|
Result run(Function &, FunctionAnalysisManager &) { return Result(); }
|
2015-01-06 10:50:06 +08:00
|
|
|
static StringRef name() { return "NoOpFunctionAnalysis"; }
|
|
|
|
};
|
|
|
|
|
2016-02-25 15:23:08 +08:00
|
|
|
/// \brief No-op loop pass which does nothing.
|
|
|
|
struct NoOpLoopPass {
|
2016-08-09 08:28:52 +08:00
|
|
|
PreservedAnalyses run(Loop &L, LoopAnalysisManager &) {
|
2016-06-17 08:11:01 +08:00
|
|
|
return PreservedAnalyses::all();
|
|
|
|
}
|
2016-02-25 15:23:08 +08:00
|
|
|
static StringRef name() { return "NoOpLoopPass"; }
|
|
|
|
};
|
|
|
|
|
|
|
|
/// \brief No-op loop analysis.
|
2016-03-11 18:33:22 +08:00
|
|
|
class NoOpLoopAnalysis : public AnalysisInfoMixin<NoOpLoopAnalysis> {
|
|
|
|
friend AnalysisInfoMixin<NoOpLoopAnalysis>;
|
2016-11-24 01:53:26 +08:00
|
|
|
static AnalysisKey Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
|
|
|
public:
|
2016-02-25 15:23:08 +08:00
|
|
|
struct Result {};
|
2016-08-09 08:28:52 +08:00
|
|
|
Result run(Loop &, LoopAnalysisManager &) { return Result(); }
|
2016-02-25 15:23:08 +08:00
|
|
|
static StringRef name() { return "NoOpLoopAnalysis"; }
|
|
|
|
};
|
|
|
|
|
2016-11-24 01:53:26 +08:00
|
|
|
AnalysisKey NoOpModuleAnalysis::Key;
|
|
|
|
AnalysisKey NoOpCGSCCAnalysis::Key;
|
|
|
|
AnalysisKey NoOpFunctionAnalysis::Key;
|
|
|
|
AnalysisKey NoOpLoopAnalysis::Key;
|
2016-03-11 18:22:49 +08:00
|
|
|
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
} // End anonymous namespace.
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
void PassBuilder::registerModuleAnalyses(ModuleAnalysisManager &MAM) {
|
2016-06-17 15:15:29 +08:00
|
|
|
#define MODULE_ANALYSIS(NAME, CREATE_PASS) \
|
2016-02-18 17:45:17 +08:00
|
|
|
MAM.registerPass([&] { return CREATE_PASS; });
|
2015-01-06 10:21:37 +08:00
|
|
|
#include "PassRegistry.def"
|
|
|
|
}
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
void PassBuilder::registerCGSCCAnalyses(CGSCCAnalysisManager &CGAM) {
|
2016-06-17 15:15:29 +08:00
|
|
|
#define CGSCC_ANALYSIS(NAME, CREATE_PASS) \
|
2016-02-18 17:45:17 +08:00
|
|
|
CGAM.registerPass([&] { return CREATE_PASS; });
|
2015-01-06 10:21:37 +08:00
|
|
|
#include "PassRegistry.def"
|
|
|
|
}
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
|
2016-06-17 15:15:29 +08:00
|
|
|
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS) \
|
2016-02-18 17:45:17 +08:00
|
|
|
FAM.registerPass([&] { return CREATE_PASS; });
|
2015-01-06 10:21:37 +08:00
|
|
|
#include "PassRegistry.def"
|
|
|
|
}
|
|
|
|
|
2016-02-25 15:23:08 +08:00
|
|
|
void PassBuilder::registerLoopAnalyses(LoopAnalysisManager &LAM) {
|
2016-06-17 15:15:29 +08:00
|
|
|
#define LOOP_ANALYSIS(NAME, CREATE_PASS) \
|
2016-02-25 15:23:08 +08:00
|
|
|
LAM.registerPass([&] { return CREATE_PASS; });
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
}
|
|
|
|
|
2016-02-29 06:16:03 +08:00
|
|
|
void PassBuilder::addPerModuleDefaultPipeline(ModulePassManager &MPM,
|
|
|
|
OptimizationLevel Level,
|
|
|
|
bool DebugLogging) {
|
|
|
|
// FIXME: Finish fleshing this out to match the legacy pipelines.
|
|
|
|
FunctionPassManager EarlyFPM(DebugLogging);
|
|
|
|
EarlyFPM.addPass(SimplifyCFGPass());
|
|
|
|
EarlyFPM.addPass(SROA());
|
|
|
|
EarlyFPM.addPass(EarlyCSEPass());
|
|
|
|
EarlyFPM.addPass(LowerExpectIntrinsicPass());
|
|
|
|
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(EarlyFPM)));
|
|
|
|
}
|
|
|
|
|
|
|
|
void PassBuilder::addLTOPreLinkDefaultPipeline(ModulePassManager &MPM,
|
|
|
|
OptimizationLevel Level,
|
|
|
|
bool DebugLogging) {
|
|
|
|
// FIXME: We should use a customized pre-link pipeline!
|
|
|
|
addPerModuleDefaultPipeline(MPM, Level, DebugLogging);
|
|
|
|
}
|
|
|
|
|
|
|
|
void PassBuilder::addLTODefaultPipeline(ModulePassManager &MPM,
|
|
|
|
OptimizationLevel Level,
|
|
|
|
bool DebugLogging) {
|
|
|
|
// FIXME: Finish fleshing this out to match the legacy LTO pipelines.
|
|
|
|
FunctionPassManager LateFPM(DebugLogging);
|
|
|
|
LateFPM.addPass(InstCombinePass());
|
|
|
|
LateFPM.addPass(SimplifyCFGPass());
|
|
|
|
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(LateFPM)));
|
|
|
|
}
|
|
|
|
|
2016-08-03 15:44:48 +08:00
|
|
|
static Optional<int> parseRepeatPassName(StringRef Name) {
|
|
|
|
if (!Name.consume_front("repeat<") || !Name.consume_back(">"))
|
|
|
|
return None;
|
|
|
|
int Count;
|
|
|
|
if (Name.getAsInteger(0, Count) || Count <= 0)
|
|
|
|
return None;
|
|
|
|
return Count;
|
|
|
|
}
|
|
|
|
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
static bool isModulePassName(StringRef Name) {
|
2016-02-29 06:16:03 +08:00
|
|
|
// Manually handle aliases for pre-configured pipeline fragments.
|
|
|
|
if (Name.startswith("default") || Name.startswith("lto"))
|
|
|
|
return DefaultAliasRegex.match(Name);
|
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
// Explicitly handle pass manager names.
|
|
|
|
if (Name == "module")
|
|
|
|
return true;
|
|
|
|
if (Name == "cgscc")
|
|
|
|
return true;
|
|
|
|
if (Name == "function")
|
|
|
|
return true;
|
|
|
|
|
2016-08-03 15:44:48 +08:00
|
|
|
// Explicitly handle custom-parsed pass names.
|
|
|
|
if (parseRepeatPassName(Name))
|
|
|
|
return true;
|
|
|
|
|
2016-06-17 15:15:29 +08:00
|
|
|
#define MODULE_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) \
|
|
|
|
return true;
|
2015-01-06 10:10:51 +08:00
|
|
|
#define MODULE_ANALYSIS(NAME, CREATE_PASS) \
|
2015-01-06 12:49:44 +08:00
|
|
|
if (Name == "require<" NAME ">" || Name == "invalidate<" NAME ">") \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true;
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-04-21 19:12:00 +08:00
|
|
|
static bool isCGSCCPassName(StringRef Name) {
|
2016-08-03 11:21:41 +08:00
|
|
|
// Explicitly handle pass manager names.
|
|
|
|
if (Name == "cgscc")
|
|
|
|
return true;
|
|
|
|
if (Name == "function")
|
|
|
|
return true;
|
|
|
|
|
2016-08-03 15:44:48 +08:00
|
|
|
// Explicitly handle custom-parsed pass names.
|
|
|
|
if (parseRepeatPassName(Name))
|
|
|
|
return true;
|
|
|
|
|
2016-06-17 15:15:29 +08:00
|
|
|
#define CGSCC_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) \
|
|
|
|
return true;
|
2015-01-06 10:10:51 +08:00
|
|
|
#define CGSCC_ANALYSIS(NAME, CREATE_PASS) \
|
2015-01-06 12:49:44 +08:00
|
|
|
if (Name == "require<" NAME ">" || Name == "invalidate<" NAME ">") \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true;
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
2014-04-21 19:12:00 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-01-12 17:34:22 +08:00
|
|
|
static bool isFunctionPassName(StringRef Name) {
|
2016-08-03 11:21:41 +08:00
|
|
|
// Explicitly handle pass manager names.
|
|
|
|
if (Name == "function")
|
|
|
|
return true;
|
|
|
|
if (Name == "loop")
|
|
|
|
return true;
|
|
|
|
|
2016-08-03 15:44:48 +08:00
|
|
|
// Explicitly handle custom-parsed pass names.
|
|
|
|
if (parseRepeatPassName(Name))
|
|
|
|
return true;
|
|
|
|
|
2016-06-17 15:15:29 +08:00
|
|
|
#define FUNCTION_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) \
|
|
|
|
return true;
|
2015-01-06 10:10:51 +08:00
|
|
|
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS) \
|
2015-01-06 12:49:44 +08:00
|
|
|
if (Name == "require<" NAME ">" || Name == "invalidate<" NAME ">") \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true;
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
2014-01-12 17:34:22 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-25 15:23:08 +08:00
|
|
|
static bool isLoopPassName(StringRef Name) {
|
2016-08-03 11:21:41 +08:00
|
|
|
// Explicitly handle pass manager names.
|
|
|
|
if (Name == "loop")
|
|
|
|
return true;
|
|
|
|
|
2016-08-03 15:44:48 +08:00
|
|
|
// Explicitly handle custom-parsed pass names.
|
|
|
|
if (parseRepeatPassName(Name))
|
|
|
|
return true;
|
|
|
|
|
2016-06-17 15:15:29 +08:00
|
|
|
#define LOOP_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) \
|
|
|
|
return true;
|
2016-02-25 15:23:08 +08:00
|
|
|
#define LOOP_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == "require<" NAME ">" || Name == "invalidate<" NAME ">") \
|
|
|
|
return true;
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
Optional<std::vector<PassBuilder::PipelineElement>>
|
|
|
|
PassBuilder::parsePipelineText(StringRef Text) {
|
|
|
|
std::vector<PipelineElement> ResultPipeline;
|
|
|
|
|
|
|
|
SmallVector<std::vector<PipelineElement> *, 4> PipelineStack = {
|
|
|
|
&ResultPipeline};
|
|
|
|
for (;;) {
|
|
|
|
std::vector<PipelineElement> &Pipeline = *PipelineStack.back();
|
|
|
|
size_t Pos = Text.find_first_of(",()");
|
|
|
|
Pipeline.push_back({Text.substr(0, Pos), {}});
|
|
|
|
|
|
|
|
// If we have a single terminating name, we're done.
|
|
|
|
if (Pos == Text.npos)
|
|
|
|
break;
|
|
|
|
|
|
|
|
char Sep = Text[Pos];
|
|
|
|
Text = Text.substr(Pos + 1);
|
|
|
|
if (Sep == ',')
|
|
|
|
// Just a name ending in a comma, continue.
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (Sep == '(') {
|
|
|
|
// Push the inner pipeline onto the stack to continue processing.
|
|
|
|
PipelineStack.push_back(&Pipeline.back().InnerPipeline);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
assert(Sep == ')' && "Bogus separator!");
|
|
|
|
// When handling the close parenthesis, we greedily consume them to avoid
|
|
|
|
// empty strings in the pipeline.
|
|
|
|
do {
|
|
|
|
// If we try to pop the outer pipeline we have unbalanced parentheses.
|
|
|
|
if (PipelineStack.size() == 1)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
PipelineStack.pop_back();
|
|
|
|
} while (Text.consume_front(")"));
|
|
|
|
|
|
|
|
// Check if we've finished parsing.
|
|
|
|
if (Text.empty())
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Otherwise, the end of an inner pipeline always has to be followed by
|
|
|
|
// a comma, and then we can continue.
|
|
|
|
if (!Text.consume_front(","))
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (PipelineStack.size() > 1)
|
|
|
|
// Unbalanced paretheses.
|
|
|
|
return None;
|
|
|
|
|
|
|
|
assert(PipelineStack.back() == &ResultPipeline &&
|
|
|
|
"Wrong pipeline at the bottom of the stack!");
|
|
|
|
return {std::move(ResultPipeline)};
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PassBuilder::parseModulePass(ModulePassManager &MPM,
|
|
|
|
const PipelineElement &E, bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
|
|
|
auto &Name = E.Name;
|
|
|
|
auto &InnerPipeline = E.InnerPipeline;
|
|
|
|
|
|
|
|
// First handle complex passes like the pass managers which carry pipelines.
|
|
|
|
if (!InnerPipeline.empty()) {
|
|
|
|
if (Name == "module") {
|
|
|
|
ModulePassManager NestedMPM(DebugLogging);
|
|
|
|
if (!parseModulePassPipeline(NestedMPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
MPM.addPass(std::move(NestedMPM));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (Name == "cgscc") {
|
|
|
|
CGSCCPassManager CGPM(DebugLogging);
|
|
|
|
if (!parseCGSCCPassPipeline(CGPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM),
|
|
|
|
DebugLogging));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (Name == "function") {
|
|
|
|
FunctionPassManager FPM(DebugLogging);
|
|
|
|
if (!parseFunctionPassPipeline(FPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
|
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 15:44:48 +08:00
|
|
|
if (auto Count = parseRepeatPassName(Name)) {
|
|
|
|
ModulePassManager NestedMPM(DebugLogging);
|
|
|
|
if (!parseModulePassPipeline(NestedMPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
2016-08-04 11:52:53 +08:00
|
|
|
MPM.addPass(createRepeatedPass(*Count, std::move(NestedMPM)));
|
2016-08-03 15:44:48 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
// Normal passes can't have pipelines.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-29 06:16:03 +08:00
|
|
|
// Manually handle aliases for pre-configured pipeline fragments.
|
|
|
|
if (Name.startswith("default") || Name.startswith("lto")) {
|
|
|
|
SmallVector<StringRef, 3> Matches;
|
|
|
|
if (!DefaultAliasRegex.match(Name, &Matches))
|
|
|
|
return false;
|
|
|
|
assert(Matches.size() == 3 && "Must capture two matched strings!");
|
|
|
|
|
2016-07-26 02:34:51 +08:00
|
|
|
OptimizationLevel L = StringSwitch<OptimizationLevel>(Matches[2])
|
|
|
|
.Case("O0", O0)
|
|
|
|
.Case("O1", O1)
|
|
|
|
.Case("O2", O2)
|
|
|
|
.Case("O3", O3)
|
|
|
|
.Case("Os", Os)
|
|
|
|
.Case("Oz", Oz);
|
2016-02-29 06:16:03 +08:00
|
|
|
|
|
|
|
if (Matches[1] == "default") {
|
|
|
|
addPerModuleDefaultPipeline(MPM, L, DebugLogging);
|
|
|
|
} else if (Matches[1] == "lto-pre-link") {
|
|
|
|
addLTOPreLinkDefaultPipeline(MPM, L, DebugLogging);
|
|
|
|
} else {
|
|
|
|
assert(Matches[1] == "lto" && "Not one of the matched options!");
|
|
|
|
addLTODefaultPipeline(MPM, L, DebugLogging);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
// Finally expand the basic registered passes from the .inc file.
|
2014-04-21 16:08:50 +08:00
|
|
|
#define MODULE_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
|
|
|
MPM.addPass(CREATE_PASS); \
|
|
|
|
return true; \
|
2014-02-06 12:37:03 +08:00
|
|
|
}
|
2015-01-06 10:10:51 +08:00
|
|
|
#define MODULE_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == "require<" NAME ">") { \
|
2016-08-20 02:36:06 +08:00
|
|
|
MPM.addPass( \
|
|
|
|
RequireAnalysisPass< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type, Module>()); \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true; \
|
2015-01-06 12:49:44 +08:00
|
|
|
} \
|
|
|
|
if (Name == "invalidate<" NAME ">") { \
|
2016-02-26 20:30:18 +08:00
|
|
|
MPM.addPass(InvalidateAnalysisPass< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>()); \
|
2015-01-06 12:49:44 +08:00
|
|
|
return true; \
|
2015-01-06 10:10:51 +08:00
|
|
|
}
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
bool PassBuilder::parseCGSCCPass(CGSCCPassManager &CGPM,
|
|
|
|
const PipelineElement &E, bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
|
|
|
auto &Name = E.Name;
|
|
|
|
auto &InnerPipeline = E.InnerPipeline;
|
|
|
|
|
|
|
|
// First handle complex passes like the pass managers which carry pipelines.
|
|
|
|
if (!InnerPipeline.empty()) {
|
|
|
|
if (Name == "cgscc") {
|
|
|
|
CGSCCPassManager NestedCGPM(DebugLogging);
|
|
|
|
if (!parseCGSCCPassPipeline(NestedCGPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
// Add the nested pass manager with the appropriate adaptor.
|
|
|
|
CGPM.addPass(std::move(NestedCGPM));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (Name == "function") {
|
|
|
|
FunctionPassManager FPM(DebugLogging);
|
|
|
|
if (!parseFunctionPassPipeline(FPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
// Add the nested pass manager with the appropriate adaptor.
|
|
|
|
CGPM.addPass(
|
|
|
|
createCGSCCToFunctionPassAdaptor(std::move(FPM), DebugLogging));
|
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 15:44:48 +08:00
|
|
|
if (auto Count = parseRepeatPassName(Name)) {
|
|
|
|
CGSCCPassManager NestedCGPM(DebugLogging);
|
|
|
|
if (!parseCGSCCPassPipeline(NestedCGPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
2016-08-04 11:52:53 +08:00
|
|
|
CGPM.addPass(createRepeatedPass(*Count, std::move(NestedCGPM)));
|
2016-08-03 15:44:48 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
// Normal passes can't have pipelines.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now expand the basic registered passes from the .inc file.
|
2014-04-21 19:12:00 +08:00
|
|
|
#define CGSCC_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
|
|
|
CGPM.addPass(CREATE_PASS); \
|
|
|
|
return true; \
|
|
|
|
}
|
2015-01-06 10:10:51 +08:00
|
|
|
#define CGSCC_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == "require<" NAME ">") { \
|
2016-02-26 20:30:18 +08:00
|
|
|
CGPM.addPass(RequireAnalysisPass< \
|
2016-08-20 02:36:06 +08:00
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type, \
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 17:37:14 +08:00
|
|
|
LazyCallGraph::SCC, CGSCCAnalysisManager, LazyCallGraph &, \
|
|
|
|
CGSCCUpdateResult &>()); \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true; \
|
2015-01-06 12:49:44 +08:00
|
|
|
} \
|
|
|
|
if (Name == "invalidate<" NAME ">") { \
|
2016-02-26 20:30:18 +08:00
|
|
|
CGPM.addPass(InvalidateAnalysisPass< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>()); \
|
2015-01-06 12:49:44 +08:00
|
|
|
return true; \
|
2015-01-06 10:10:51 +08:00
|
|
|
}
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
2014-04-21 19:12:00 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
bool PassBuilder::parseFunctionPass(FunctionPassManager &FPM,
|
|
|
|
const PipelineElement &E,
|
|
|
|
bool VerifyEachPass, bool DebugLogging) {
|
|
|
|
auto &Name = E.Name;
|
|
|
|
auto &InnerPipeline = E.InnerPipeline;
|
|
|
|
|
|
|
|
// First handle complex passes like the pass managers which carry pipelines.
|
|
|
|
if (!InnerPipeline.empty()) {
|
|
|
|
if (Name == "function") {
|
|
|
|
FunctionPassManager NestedFPM(DebugLogging);
|
|
|
|
if (!parseFunctionPassPipeline(NestedFPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
// Add the nested pass manager with the appropriate adaptor.
|
|
|
|
FPM.addPass(std::move(NestedFPM));
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (Name == "loop") {
|
|
|
|
LoopPassManager LPM(DebugLogging);
|
|
|
|
if (!parseLoopPassPipeline(LPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
// Add the nested pass manager with the appropriate adaptor.
|
|
|
|
FPM.addPass(createFunctionToLoopPassAdaptor(std::move(LPM)));
|
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 15:44:48 +08:00
|
|
|
if (auto Count = parseRepeatPassName(Name)) {
|
|
|
|
FunctionPassManager NestedFPM(DebugLogging);
|
|
|
|
if (!parseFunctionPassPipeline(NestedFPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
2016-08-04 11:52:53 +08:00
|
|
|
FPM.addPass(createRepeatedPass(*Count, std::move(NestedFPM)));
|
2016-08-03 15:44:48 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
// Normal passes can't have pipelines.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now expand the basic registered passes from the .inc file.
|
2014-04-21 16:08:50 +08:00
|
|
|
#define FUNCTION_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
|
|
|
FPM.addPass(CREATE_PASS); \
|
|
|
|
return true; \
|
2014-01-12 20:15:39 +08:00
|
|
|
}
|
2015-01-06 10:10:51 +08:00
|
|
|
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == "require<" NAME ">") { \
|
2016-08-20 02:36:06 +08:00
|
|
|
FPM.addPass( \
|
|
|
|
RequireAnalysisPass< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type, Function>()); \
|
2015-01-06 10:10:51 +08:00
|
|
|
return true; \
|
2015-01-06 12:49:44 +08:00
|
|
|
} \
|
|
|
|
if (Name == "invalidate<" NAME ">") { \
|
2016-02-26 20:30:18 +08:00
|
|
|
FPM.addPass(InvalidateAnalysisPass< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>()); \
|
2015-01-06 12:49:44 +08:00
|
|
|
return true; \
|
2015-01-06 10:10:51 +08:00
|
|
|
}
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
2014-01-12 17:34:22 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-03 17:14:03 +08:00
|
|
|
bool PassBuilder::parseLoopPass(LoopPassManager &LPM, const PipelineElement &E,
|
2016-08-03 11:21:41 +08:00
|
|
|
bool VerifyEachPass, bool DebugLogging) {
|
2016-08-03 15:44:48 +08:00
|
|
|
StringRef Name = E.Name;
|
2016-08-03 11:21:41 +08:00
|
|
|
auto &InnerPipeline = E.InnerPipeline;
|
|
|
|
|
|
|
|
// First handle complex passes like the pass managers which carry pipelines.
|
|
|
|
if (!InnerPipeline.empty()) {
|
|
|
|
if (Name == "loop") {
|
|
|
|
LoopPassManager NestedLPM(DebugLogging);
|
|
|
|
if (!parseLoopPassPipeline(NestedLPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
|
|
|
// Add the nested pass manager with the appropriate adaptor.
|
2016-08-03 17:14:03 +08:00
|
|
|
LPM.addPass(std::move(NestedLPM));
|
2016-08-03 11:21:41 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 15:44:48 +08:00
|
|
|
if (auto Count = parseRepeatPassName(Name)) {
|
|
|
|
LoopPassManager NestedLPM(DebugLogging);
|
|
|
|
if (!parseLoopPassPipeline(NestedLPM, InnerPipeline, VerifyEachPass,
|
|
|
|
DebugLogging))
|
|
|
|
return false;
|
2016-08-04 11:52:53 +08:00
|
|
|
LPM.addPass(createRepeatedPass(*Count, std::move(NestedLPM)));
|
2016-08-03 15:44:48 +08:00
|
|
|
return true;
|
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
// Normal passes can't have pipelines.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now expand the basic registered passes from the .inc file.
|
2016-02-25 15:23:08 +08:00
|
|
|
#define LOOP_PASS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
2016-08-03 17:14:03 +08:00
|
|
|
LPM.addPass(CREATE_PASS); \
|
2016-02-25 15:23:08 +08:00
|
|
|
return true; \
|
|
|
|
}
|
|
|
|
#define LOOP_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == "require<" NAME ">") { \
|
2016-08-03 17:14:03 +08:00
|
|
|
LPM.addPass(RequireAnalysisPass< \
|
2016-08-20 02:36:06 +08:00
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type, Loop>()); \
|
2016-02-25 15:23:08 +08:00
|
|
|
return true; \
|
|
|
|
} \
|
|
|
|
if (Name == "invalidate<" NAME ">") { \
|
2016-08-03 17:14:03 +08:00
|
|
|
LPM.addPass(InvalidateAnalysisPass< \
|
2016-02-26 20:30:18 +08:00
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>()); \
|
2016-02-25 15:23:08 +08:00
|
|
|
return true; \
|
|
|
|
}
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-18 17:45:17 +08:00
|
|
|
bool PassBuilder::parseAAPassName(AAManager &AA, StringRef Name) {
|
2016-03-11 17:15:11 +08:00
|
|
|
#define MODULE_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
|
|
|
AA.registerModuleAnalysis< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>(); \
|
|
|
|
return true; \
|
|
|
|
}
|
2016-02-18 17:45:17 +08:00
|
|
|
#define FUNCTION_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
if (Name == NAME) { \
|
2016-02-26 20:17:54 +08:00
|
|
|
AA.registerFunctionAnalysis< \
|
|
|
|
std::remove_reference<decltype(CREATE_PASS)>::type>(); \
|
2016-02-18 17:45:17 +08:00
|
|
|
return true; \
|
|
|
|
}
|
|
|
|
#include "PassRegistry.def"
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-02-25 15:23:08 +08:00
|
|
|
bool PassBuilder::parseLoopPassPipeline(LoopPassManager &LPM,
|
2016-08-03 11:21:41 +08:00
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2016-02-25 15:23:08 +08:00
|
|
|
bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
2016-08-03 11:21:41 +08:00
|
|
|
for (const auto &Element : Pipeline) {
|
|
|
|
if (!parseLoopPass(LPM, Element, VerifyEachPass, DebugLogging))
|
|
|
|
return false;
|
|
|
|
// FIXME: No verifier support for Loop passes!
|
2016-02-25 15:23:08 +08:00
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
return true;
|
2016-02-25 15:23:08 +08:00
|
|
|
}
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
bool PassBuilder::parseFunctionPassPipeline(FunctionPassManager &FPM,
|
2016-08-03 11:21:41 +08:00
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2015-03-07 17:02:36 +08:00
|
|
|
bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
2016-08-03 11:21:41 +08:00
|
|
|
for (const auto &Element : Pipeline) {
|
|
|
|
if (!parseFunctionPass(FPM, Element, VerifyEachPass, DebugLogging))
|
|
|
|
return false;
|
|
|
|
if (VerifyEachPass)
|
|
|
|
FPM.addPass(VerifierPass());
|
2014-01-12 17:34:22 +08:00
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
return true;
|
2014-01-12 17:34:22 +08:00
|
|
|
}
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
bool PassBuilder::parseCGSCCPassPipeline(CGSCCPassManager &CGPM,
|
2016-08-03 11:21:41 +08:00
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2015-03-07 17:02:36 +08:00
|
|
|
bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
2016-08-03 11:21:41 +08:00
|
|
|
for (const auto &Element : Pipeline) {
|
|
|
|
if (!parseCGSCCPass(CGPM, Element, VerifyEachPass, DebugLogging))
|
|
|
|
return false;
|
|
|
|
// FIXME: No verifier support for CGSCC passes!
|
2014-04-21 19:12:00 +08:00
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
return true;
|
2014-04-21 19:12:00 +08:00
|
|
|
}
|
|
|
|
|
2016-05-16 18:13:37 +08:00
|
|
|
void PassBuilder::crossRegisterProxies(LoopAnalysisManager &LAM,
|
|
|
|
FunctionAnalysisManager &FAM,
|
|
|
|
CGSCCAnalysisManager &CGAM,
|
|
|
|
ModuleAnalysisManager &MAM) {
|
|
|
|
MAM.registerPass([&] { return FunctionAnalysisManagerModuleProxy(FAM); });
|
|
|
|
MAM.registerPass([&] { return CGSCCAnalysisManagerModuleProxy(CGAM); });
|
|
|
|
CGAM.registerPass([&] { return ModuleAnalysisManagerCGSCCProxy(MAM); });
|
|
|
|
FAM.registerPass([&] { return CGSCCAnalysisManagerFunctionProxy(CGAM); });
|
|
|
|
FAM.registerPass([&] { return ModuleAnalysisManagerFunctionProxy(MAM); });
|
|
|
|
FAM.registerPass([&] { return LoopAnalysisManagerFunctionProxy(LAM); });
|
|
|
|
LAM.registerPass([&] { return FunctionAnalysisManagerLoopProxy(FAM); });
|
|
|
|
}
|
|
|
|
|
2015-03-07 17:02:36 +08:00
|
|
|
bool PassBuilder::parseModulePassPipeline(ModulePassManager &MPM,
|
2016-08-03 11:21:41 +08:00
|
|
|
ArrayRef<PipelineElement> Pipeline,
|
2015-03-07 17:02:36 +08:00
|
|
|
bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
2016-08-03 11:21:41 +08:00
|
|
|
for (const auto &Element : Pipeline) {
|
|
|
|
if (!parseModulePass(MPM, Element, VerifyEachPass, DebugLogging))
|
|
|
|
return false;
|
|
|
|
if (VerifyEachPass)
|
|
|
|
MPM.addPass(VerifierPass());
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
}
|
2016-08-03 11:21:41 +08:00
|
|
|
return true;
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Primary pass pipeline description parsing routine.
|
|
|
|
// FIXME: Should this routine accept a TargetMachine or require the caller to
|
|
|
|
// pre-populate the analysis managers with target-specific stuff?
|
2015-03-07 17:02:36 +08:00
|
|
|
bool PassBuilder::parsePassPipeline(ModulePassManager &MPM,
|
|
|
|
StringRef PipelineText, bool VerifyEachPass,
|
|
|
|
bool DebugLogging) {
|
2016-08-03 11:21:41 +08:00
|
|
|
auto Pipeline = parsePipelineText(PipelineText);
|
|
|
|
if (!Pipeline || Pipeline->empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If the first name isn't at the module layer, wrap the pipeline up
|
|
|
|
// automatically.
|
|
|
|
StringRef FirstName = Pipeline->front().Name;
|
|
|
|
|
|
|
|
if (!isModulePassName(FirstName)) {
|
|
|
|
if (isCGSCCPassName(FirstName))
|
|
|
|
Pipeline = {{"cgscc", std::move(*Pipeline)}};
|
|
|
|
else if (isFunctionPassName(FirstName))
|
|
|
|
Pipeline = {{"function", std::move(*Pipeline)}};
|
|
|
|
else if (isLoopPassName(FirstName))
|
|
|
|
Pipeline = {{"function", {{"loop", std::move(*Pipeline)}}}};
|
|
|
|
else
|
|
|
|
// Unknown pass name!
|
2014-04-21 19:12:00 +08:00
|
|
|
return false;
|
2014-01-12 17:34:22 +08:00
|
|
|
}
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
|
2016-08-03 11:21:41 +08:00
|
|
|
return parseModulePassPipeline(MPM, *Pipeline, VerifyEachPass, DebugLogging);
|
[PM] Add (very skeletal) support to opt for running the new pass
manager. I cannot emphasize enough that this is a WIP. =] I expect it
to change a great deal as things stabilize, but I think its really
important to get *some* functionality here so that the infrastructure
can be tested more traditionally from the commandline.
The current design is looking something like this:
./bin/opt -passes='module(pass_a,pass_b,function(pass_c,pass_d))'
So rather than custom-parsed flags, there is a single flag with a string
argument that is parsed into the pass pipeline structure. This makes it
really easy to have nice structural properties that are very explicit.
There is one obvious and important shortcut. You can start off the
pipeline with a pass, and the minimal context of pass managers will be
built around the entire specified pipeline. This makes the common case
for tests super easy:
./bin/opt -passes=instcombine,sroa,gvn
But this won't introduce any of the complexity of the fully inferred old
system -- we only ever do this for the *entire* argument, and we only
look at the first pass. If the other passes don't fit in the pass
manager selected it is a hard error.
The other interesting aspect here is that I'm not relying on any
registration facilities. Such facilities may be unavoidable for
supporting plugins, but I have alternative ideas for plugins that I'd
like to try first. My plan is essentially to build everything without
registration until we hit an absolute requirement.
Instead of registration of pass names, there will be a library dedicated
to parsing pass names and the pass pipeline strings described above.
Currently, this is directly embedded into opt for simplicity as it is
very early, but I plan to eventually pull this into a library that opt,
bugpoint, and even Clang can depend on. It should end up as a good home
for things like the existing PassManagerBuilder as well.
There are a bunch of FIXMEs in the code for the parts of this that are
just stubbed out to make the patch more incremental. A quick list of
what's coming up directly after this:
- Support for function passes and building the structured nesting.
- Support for printing the pass structure, and FileCheck tests of all of
this code.
- The .def-file based pass name parsing.
- IR priting passes and the corresponding tests.
Some obvious things that I'm not going to do right now, but am
definitely planning on as the pass manager work gets a bit further:
- Pull the parsing into library, including the builders.
- Thread the rest of the target stuff into the new pass manager.
- Wire support for the new pass manager up to llc.
- Plugin support.
Some things that I'd like to have, but are significantly lower on my
priority list. I'll get to these eventually, but they may also be places
where others want to contribute:
- Adding nice error reporting for broken pass pipeline descriptions.
- Typo-correction for pass names.
llvm-svn: 198998
2014-01-11 16:16:35 +08:00
|
|
|
}
|
2016-02-18 17:45:17 +08:00
|
|
|
|
|
|
|
bool PassBuilder::parseAAPipeline(AAManager &AA, StringRef PipelineText) {
|
|
|
|
while (!PipelineText.empty()) {
|
|
|
|
StringRef Name;
|
|
|
|
std::tie(Name, PipelineText) = PipelineText.split(',');
|
|
|
|
if (!parseAAPassName(AA, Name))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|