2014-04-21 16:08:50 +08:00
|
|
|
//===- PassRegistry.def - Registry of passes --------------------*- C++ -*-===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// This file is used as the registry of passes that are part of the core LLVM
|
|
|
|
|
// libraries. This file describes both transformation passes and analyses
|
|
|
|
|
// Analyses are registered while transformation passes have names registered
|
|
|
|
|
// that can be used when providing a textual pass pipeline.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
// NOTE: NO INCLUDE GUARD DESIRED!
|
|
|
|
|
|
2014-04-21 16:20:10 +08:00
|
|
|
#ifndef MODULE_ANALYSIS
|
|
|
|
|
#define MODULE_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2016-03-10 19:24:11 +08:00
|
|
|
MODULE_ANALYSIS("callgraph", CallGraphAnalysis())
|
2014-04-21 16:20:10 +08:00
|
|
|
MODULE_ANALYSIS("lcg", LazyCallGraphAnalysis())
|
2015-01-06 10:50:06 +08:00
|
|
|
MODULE_ANALYSIS("no-op-module", NoOpModuleAnalysis())
|
2016-06-04 06:54:26 +08:00
|
|
|
MODULE_ANALYSIS("profile-summary", ProfileSummaryAnalysis())
|
2015-01-15 19:39:46 +08:00
|
|
|
MODULE_ANALYSIS("targetlibinfo", TargetLibraryAnalysis())
|
2016-05-10 03:57:29 +08:00
|
|
|
MODULE_ANALYSIS("verify", VerifierAnalysis())
|
2016-03-11 17:15:11 +08:00
|
|
|
|
|
|
|
|
#ifndef MODULE_ALIAS_ANALYSIS
|
|
|
|
|
#define MODULE_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
|
MODULE_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
MODULE_ALIAS_ANALYSIS("globals-aa", GlobalsAA())
|
|
|
|
|
#undef MODULE_ALIAS_ANALYSIS
|
2014-04-21 16:20:10 +08:00
|
|
|
#undef MODULE_ANALYSIS
|
|
|
|
|
|
2014-04-21 16:08:50 +08:00
|
|
|
#ifndef MODULE_PASS
|
|
|
|
|
#define MODULE_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2016-05-05 08:51:09 +08:00
|
|
|
MODULE_PASS("constmerge", ConstantMergePass())
|
2016-06-12 17:16:39 +08:00
|
|
|
MODULE_PASS("deadargelim", DeadArgumentEliminationPass())
|
2016-05-05 10:37:32 +08:00
|
|
|
MODULE_PASS("elim-avail-extern", EliminateAvailableExternallyPass())
|
2015-12-27 16:13:45 +08:00
|
|
|
MODULE_PASS("forceattrs", ForceFunctionAttrsPass())
|
2016-05-04 03:39:15 +08:00
|
|
|
MODULE_PASS("globaldce", GlobalDCEPass())
|
2016-04-26 08:28:01 +08:00
|
|
|
MODULE_PASS("globalopt", GlobalOptPass())
|
2015-12-27 16:41:34 +08:00
|
|
|
MODULE_PASS("inferattrs", InferFunctionAttrsPass())
|
2016-06-05 13:12:23 +08:00
|
|
|
MODULE_PASS("insert-gcov-profiling", GCOVProfilerPass())
|
2016-04-19 01:47:38 +08:00
|
|
|
MODULE_PASS("instrprof", InstrProfiling())
|
2016-06-05 13:15:45 +08:00
|
|
|
MODULE_PASS("internalize", InternalizePass())
|
2015-01-06 17:06:35 +08:00
|
|
|
MODULE_PASS("invalidate<all>", InvalidateAllAnalysesPass())
|
2016-05-06 05:05:36 +08:00
|
|
|
MODULE_PASS("ipsccp", IPSCCPPass())
|
2015-01-06 10:37:55 +08:00
|
|
|
MODULE_PASS("no-op-module", NoOpModulePass())
|
2016-06-28 00:50:18 +08:00
|
|
|
MODULE_PASS("partial-inliner", PartialInlinerPass())
|
2016-05-17 00:31:07 +08:00
|
|
|
MODULE_PASS("pgo-icall-prom", PGOIndirectCallPromotion())
|
2016-05-06 13:49:19 +08:00
|
|
|
MODULE_PASS("pgo-instr-gen", PGOInstrumentationGen())
|
2016-05-11 05:59:52 +08:00
|
|
|
MODULE_PASS("pgo-instr-use", PGOInstrumentationUse())
|
2016-06-25 04:13:42 +08:00
|
|
|
MODULE_PASS("pre-isel-intrinsic-lowering", PreISelIntrinsicLoweringPass())
|
2016-06-04 06:54:26 +08:00
|
|
|
MODULE_PASS("print-profile-summary", ProfileSummaryPrinterPass(dbgs()))
|
2016-06-04 05:14:26 +08:00
|
|
|
MODULE_PASS("print-callgraph", CallGraphPrinterPass(dbgs()))
|
2016-06-04 06:54:26 +08:00
|
|
|
MODULE_PASS("print", PrintModulePass(dbgs()))
|
2016-03-10 19:24:06 +08:00
|
|
|
MODULE_PASS("print-lcg", LazyCallGraphPrinterPass(dbgs()))
|
2016-06-18 17:17:32 +08:00
|
|
|
MODULE_PASS("print-lcg-dot", LazyCallGraphDOTPrinterPass(dbgs()))
|
[PM] Port ReversePostOrderFunctionAttrs to the new PM
Below are my super rough notes when porting. They can probably serve as
a basic guide for porting other passes to the new PM. As I port more
passes I'll expand and generalize this and make a proper
docs/HowToPortToNewPassManager.rst document. There is also missing
documentation for general concepts and API's in the new PM which will
require some documentation.
Once there is proper documentation in place we can put up a list of
passes that have to be ported and game-ify/crowdsource the rest of the
porting (at least of the middle end; the backend is still unclear).
I will however be taking personal responsibility for ensuring that the
LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes
to be ported are (do something like
`git grep "<the string in the bullet point below>"` to find the pass):
General Scalar:
[ ] Simplify the CFG
[ ] Jump Threading
[ ] MemCpy Optimization
[ ] Promote Memory to Register
[ ] MergedLoadStoreMotion
[ ] Lazy Value Information Analysis
General IPO:
[ ] Dead Argument Elimination
[ ] Deduce function attributes in RPO
Loop stuff / vectorization stuff:
[ ] Alignment from assumptions
[ ] Canonicalize natural loops
[ ] Delete dead loops
[ ] Loop Access Analysis
[ ] Loop Invariant Code Motion
[ ] Loop Vectorization
[ ] SLP Vectorizer
[ ] Unroll loops
Devirtualization / CFI:
[ ] Cross-DSO CFI
[ ] Whole program devirtualization
[ ] Lower bitset metadata
CGSCC passes:
[ ] Function Integration/Inlining
[ ] Remove unused exception handling info
[ ] Promote 'by reference' arguments to scalars
Please let me know if you are interested in working on any of the passes
in the above list (e.g. reply to the post-commit thread for this patch).
I'll probably be tackling "General Scalar" and "General IPO" first FWIW.
Steps as I port "Deduce function attributes in RPO"
---------------------------------------------------
(note: if you are doing any work based on these notes, please leave a
note in the post-commit review thread for this commit with any
improvements / suggestions / incompleteness you ran into!)
Note: "Deduce function attributes in RPO" is a module pass.
1. Do preparatory refactoring.
Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503).
(TODO: give more advice here e.g. if pass holds state or something)
2. Rename the old pass class.
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass
in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM.
(edit: actually wait what? The new class name will be
ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is
sort of useless churn).
llvm/include/llvm/InitializePasses.h
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Transforms/IPO/IPO.cpp
llvm/lib/Transforms/IPO/FunctionAttrs.cpp
Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass
(note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`)
Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too.
Note that createReversePostOrderFunctionAttrsPass does not need to be
renamed since its name is not generated from the class name.
3. Add the new PM pass class.
In the new PM all passes need to have their
declaration in a header somewhere, so you will often need to add a header.
In this case
llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because
PostOrderFunctionAttrsPass was already ported.
The file-level comment from the .cpp file can be used as the file-level
comment for the new header. You may want to tweak the wording slightly
from "this file implements" to "this file provides" or similar.
Add declaration for the new PM pass in this header:
class ReversePostOrderFunctionAttrsPass
: public PassInfoMixin<ReversePostOrderFunctionAttrsPass> {
public:
PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM);
};
Its name should end with `Pass` for consistency (note that this doesn't
collide with the names of most old PM passes). E.g. call it
`<name of the old PM pass>Pass`.
Also, move the doxygen comment from the old PM pass to the declaration of
this class in the header.
Also, include the declaration for the new PM class
`llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case,
it was already done when the other pass in this file was ported).
Now define the `run` method for the new class.
The main things here are:
a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()`
b) If the old PM pass would have returned "false" (i.e. `Changed ==
false`), then you should return PreservedAnalyses::all();
c) In the old PM getAnalysisUsage method, observe the calls
`AU.addPreserved<...>();`.
In the case `Changed == true`, for each preserved analysis you should do
call `PA.preserve<...>()` on a PreservedAnalyses object and return it.
E.g.:
PreservedAnalyses PA;
PA.preserve<CallGraphAnalysis>();
return PA;
Note that calls to skipModule/skipFunction are not supported in the new PM
currently, so optnone and optimization bisect support do not work. You can
just drop those calls for now.
4. Add the pass to the new PM pass registry to make it available in opt.
In llvm/lib/Passes/PassBuilder.cpp add a #include for your header.
`#include "llvm/Transforms/IPO/FunctionAttrs.h"`
In this case there is already an include (from when
PostOrderFunctionAttrsPass was ported).
Add your pass to llvm/lib/Passes/PassRegistry.def
In this case, I added
`MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())`
The string is from the `INITIALIZE_PASS*` macros used in the old pass
manager.
Then choose a test that uses the pass and use the new PM `-passes=...` to
run it.
E.g. in this case there is a test that does:
; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s
I have added the line:
; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s
The `-aa-pipeline=basic-aa` and
`require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run
functionattrs in the new PM (note that in the new PM "functionattrs"
becomes "function-attrs" for some reason). This is just pulled from
`readattrs.ll` which contains the change from when functionattrs was ported
to the new PM.
Adding rpo-functionattrs causes the pass that was just ported to run.
llvm-svn: 272505
2016-06-12 15:48:51 +08:00
|
|
|
MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())
|
2016-05-28 07:20:16 +08:00
|
|
|
MODULE_PASS("sample-profile", SampleProfileLoaderPass())
|
2015-10-31 07:28:12 +08:00
|
|
|
MODULE_PASS("strip-dead-prototypes", StripDeadPrototypesPass())
|
2016-06-15 05:44:19 +08:00
|
|
|
MODULE_PASS("wholeprogramdevirt", WholeProgramDevirtPass())
|
2015-01-05 08:08:53 +08:00
|
|
|
MODULE_PASS("verify", VerifierPass())
|
2014-04-21 16:08:50 +08:00
|
|
|
#undef MODULE_PASS
|
|
|
|
|
|
2014-04-21 19:12:00 +08:00
|
|
|
#ifndef CGSCC_ANALYSIS
|
|
|
|
|
#define CGSCC_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2015-01-06 10:50:06 +08:00
|
|
|
CGSCC_ANALYSIS("no-op-cgscc", NoOpCGSCCAnalysis())
|
2014-04-21 19:12:00 +08:00
|
|
|
#undef CGSCC_ANALYSIS
|
|
|
|
|
|
|
|
|
|
#ifndef CGSCC_PASS
|
|
|
|
|
#define CGSCC_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2015-01-06 17:06:35 +08:00
|
|
|
CGSCC_PASS("invalidate<all>", InvalidateAllAnalysesPass())
|
2016-02-18 19:03:11 +08:00
|
|
|
CGSCC_PASS("function-attrs", PostOrderFunctionAttrsPass())
|
2015-01-06 10:37:55 +08:00
|
|
|
CGSCC_PASS("no-op-cgscc", NoOpCGSCCPass())
|
2014-04-21 19:12:00 +08:00
|
|
|
#undef CGSCC_PASS
|
|
|
|
|
|
2014-04-21 16:20:10 +08:00
|
|
|
#ifndef FUNCTION_ANALYSIS
|
|
|
|
|
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2016-02-14 07:32:00 +08:00
|
|
|
FUNCTION_ANALYSIS("aa", AAManager())
|
2015-01-23 05:53:09 +08:00
|
|
|
FUNCTION_ANALYSIS("assumptions", AssumptionAnalysis())
|
2016-05-06 05:13:27 +08:00
|
|
|
FUNCTION_ANALYSIS("block-freq", BlockFrequencyAnalysis())
|
2016-05-05 10:59:57 +08:00
|
|
|
FUNCTION_ANALYSIS("branch-prob", BranchProbabilityAnalysis())
|
2015-01-14 18:19:28 +08:00
|
|
|
FUNCTION_ANALYSIS("domtree", DominatorTreeAnalysis())
|
2016-02-26 01:54:07 +08:00
|
|
|
FUNCTION_ANALYSIS("postdomtree", PostDominatorTreeAnalysis())
|
2016-04-19 07:55:01 +08:00
|
|
|
FUNCTION_ANALYSIS("demanded-bits", DemandedBitsAnalysis())
|
2016-02-26 01:54:15 +08:00
|
|
|
FUNCTION_ANALYSIS("domfrontier", DominanceFrontierAnalysis())
|
2015-01-20 18:58:50 +08:00
|
|
|
FUNCTION_ANALYSIS("loops", LoopAnalysis())
|
2016-06-14 06:01:25 +08:00
|
|
|
FUNCTION_ANALYSIS("lazy-value-info", LazyValueAnalysis())
|
2016-05-13 06:19:39 +08:00
|
|
|
FUNCTION_ANALYSIS("da", DependenceAnalysis())
|
2016-03-10 08:55:30 +08:00
|
|
|
FUNCTION_ANALYSIS("memdep", MemoryDependenceAnalysis())
|
2016-06-02 05:30:40 +08:00
|
|
|
FUNCTION_ANALYSIS("memoryssa", MemorySSAAnalysis())
|
2016-02-26 01:54:25 +08:00
|
|
|
FUNCTION_ANALYSIS("regions", RegionInfoAnalysis())
|
2015-01-06 10:50:06 +08:00
|
|
|
FUNCTION_ANALYSIS("no-op-function", NoOpFunctionAnalysis())
|
[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
|
|
|
FUNCTION_ANALYSIS("scalar-evolution", ScalarEvolutionAnalysis())
|
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]
When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:
While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.
A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.
This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.
It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.
The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.
One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.
The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.
llvm-svn: 226981
2015-01-24 10:06:09 +08:00
|
|
|
FUNCTION_ANALYSIS("targetlibinfo", TargetLibraryAnalysis())
|
2015-02-01 18:11:22 +08:00
|
|
|
FUNCTION_ANALYSIS("targetir",
|
|
|
|
|
TM ? TM->getTargetIRAnalysis() : TargetIRAnalysis())
|
2016-05-10 03:57:29 +08:00
|
|
|
FUNCTION_ANALYSIS("verify", VerifierAnalysis())
|
2016-02-18 17:45:17 +08:00
|
|
|
|
|
|
|
|
#ifndef FUNCTION_ALIAS_ANALYSIS
|
|
|
|
|
#define FUNCTION_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
|
|
|
|
|
FUNCTION_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
FUNCTION_ALIAS_ANALYSIS("basic-aa", BasicAA())
|
2016-02-20 11:52:02 +08:00
|
|
|
FUNCTION_ALIAS_ANALYSIS("cfl-aa", CFLAA())
|
2016-02-20 12:01:45 +08:00
|
|
|
FUNCTION_ALIAS_ANALYSIS("scev-aa", SCEVAA())
|
2016-02-20 12:03:06 +08:00
|
|
|
FUNCTION_ALIAS_ANALYSIS("scoped-noalias-aa", ScopedNoAliasAA())
|
2016-02-20 12:04:52 +08:00
|
|
|
FUNCTION_ALIAS_ANALYSIS("type-based-aa", TypeBasedAA())
|
2016-02-18 17:45:17 +08:00
|
|
|
#undef FUNCTION_ALIAS_ANALYSIS
|
2014-04-21 16:20:10 +08:00
|
|
|
#undef FUNCTION_ANALYSIS
|
|
|
|
|
|
2014-04-21 16:08:50 +08:00
|
|
|
#ifndef FUNCTION_PASS
|
|
|
|
|
#define FUNCTION_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
2016-02-20 11:46:03 +08:00
|
|
|
FUNCTION_PASS("aa-eval", AAEvaluator())
|
2015-10-31 07:13:18 +08:00
|
|
|
FUNCTION_PASS("adce", ADCEPass())
|
2016-06-16 05:51:30 +08:00
|
|
|
FUNCTION_PASS("add-discriminators", AddDiscriminatorsPass())
|
2016-06-15 14:18:01 +08:00
|
|
|
FUNCTION_PASS("alignment-from-assumptions", AlignmentFromAssumptionsPass())
|
2016-05-25 09:57:04 +08:00
|
|
|
FUNCTION_PASS("bdce", BDCEPass())
|
2016-04-23 03:40:41 +08:00
|
|
|
FUNCTION_PASS("dce", DCEPass())
|
2016-05-18 05:38:13 +08:00
|
|
|
FUNCTION_PASS("dse", DSEPass())
|
2015-02-01 18:51:23 +08:00
|
|
|
FUNCTION_PASS("early-cse", EarlyCSEPass())
|
2015-01-24 12:19:17 +08:00
|
|
|
FUNCTION_PASS("instcombine", InstCombinePass())
|
2015-01-06 17:06:35 +08:00
|
|
|
FUNCTION_PASS("invalidate<all>", InvalidateAllAnalysesPass())
|
2016-06-25 07:32:02 +08:00
|
|
|
FUNCTION_PASS("float2int", Float2IntPass())
|
2015-01-06 10:37:55 +08:00
|
|
|
FUNCTION_PASS("no-op-function", NoOpFunctionPass())
|
2016-05-14 06:52:35 +08:00
|
|
|
FUNCTION_PASS("loweratomic", LowerAtomicPass())
|
2015-01-24 19:13:02 +08:00
|
|
|
FUNCTION_PASS("lower-expect", LowerExpectIntrinsicPass())
|
2016-05-19 06:55:34 +08:00
|
|
|
FUNCTION_PASS("guard-widening", GuardWideningPass())
|
2016-03-11 16:50:55 +08:00
|
|
|
FUNCTION_PASS("gvn", GVN())
|
2016-06-14 11:22:22 +08:00
|
|
|
FUNCTION_PASS("mem2reg", PromotePass())
|
2016-06-14 10:44:55 +08:00
|
|
|
FUNCTION_PASS("memcpyopt", MemCpyOptPass())
|
2016-06-18 03:10:09 +08:00
|
|
|
FUNCTION_PASS("mldst-motion", MergedLoadStoreMotionPass())
|
2016-06-14 08:51:09 +08:00
|
|
|
FUNCTION_PASS("jump-threading", JumpThreadingPass())
|
2016-05-26 07:38:53 +08:00
|
|
|
FUNCTION_PASS("partially-inline-libcalls", PartiallyInlineLibCallsPass())
|
2016-06-10 03:44:46 +08:00
|
|
|
FUNCTION_PASS("lcssa", LCSSAPass())
|
2014-04-21 16:08:50 +08:00
|
|
|
FUNCTION_PASS("print", PrintFunctionPass(dbgs()))
|
2015-01-23 05:53:09 +08:00
|
|
|
FUNCTION_PASS("print<assumptions>", AssumptionPrinterPass(dbgs()))
|
2016-05-06 05:13:27 +08:00
|
|
|
FUNCTION_PASS("print<block-freq>", BlockFrequencyPrinterPass(dbgs()))
|
2016-05-05 10:59:57 +08:00
|
|
|
FUNCTION_PASS("print<branch-prob>", BranchProbabilityPrinterPass(dbgs()))
|
2015-01-14 18:19:28 +08:00
|
|
|
FUNCTION_PASS("print<domtree>", DominatorTreePrinterPass(dbgs()))
|
2016-02-26 01:54:07 +08:00
|
|
|
FUNCTION_PASS("print<postdomtree>", PostDominatorTreePrinterPass(dbgs()))
|
2016-04-19 07:55:01 +08:00
|
|
|
FUNCTION_PASS("print<demanded-bits>", DemandedBitsPrinterPass(dbgs()))
|
2016-02-26 01:54:15 +08:00
|
|
|
FUNCTION_PASS("print<domfrontier>", DominanceFrontierPrinterPass(dbgs()))
|
2015-01-20 18:58:50 +08:00
|
|
|
FUNCTION_PASS("print<loops>", LoopPrinterPass(dbgs()))
|
2016-06-02 05:30:40 +08:00
|
|
|
FUNCTION_PASS("print<memoryssa>", MemorySSAPrinterPass(dbgs()))
|
2016-02-26 01:54:25 +08:00
|
|
|
FUNCTION_PASS("print<regions>", RegionInfoPrinterPass(dbgs()))
|
[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
|
|
|
FUNCTION_PASS("print<scalar-evolution>", ScalarEvolutionPrinterPass(dbgs()))
|
2016-04-27 07:39:29 +08:00
|
|
|
FUNCTION_PASS("reassociate", ReassociatePass())
|
2016-05-18 23:18:25 +08:00
|
|
|
FUNCTION_PASS("sccp", SCCPPass())
|
2015-02-01 19:34:21 +08:00
|
|
|
FUNCTION_PASS("simplify-cfg", SimplifyCFGPass())
|
2016-04-23 03:54:10 +08:00
|
|
|
FUNCTION_PASS("sink", SinkingPass())
|
2016-06-15 16:43:40 +08:00
|
|
|
FUNCTION_PASS("slp-vectorizer", SLPVectorizerPass())
|
2015-09-12 17:09:14 +08:00
|
|
|
FUNCTION_PASS("sroa", SROA())
|
2015-01-05 08:08:53 +08:00
|
|
|
FUNCTION_PASS("verify", VerifierPass())
|
2015-01-14 18:19:28 +08:00
|
|
|
FUNCTION_PASS("verify<domtree>", DominatorTreeVerifierPass())
|
2016-06-02 05:30:40 +08:00
|
|
|
FUNCTION_PASS("verify<memoryssa>", MemorySSAVerifierPass())
|
2016-02-26 01:54:25 +08:00
|
|
|
FUNCTION_PASS("verify<regions>", RegionInfoVerifierPass())
|
2014-04-21 16:08:50 +08:00
|
|
|
#undef FUNCTION_PASS
|
2016-02-25 15:23:08 +08:00
|
|
|
|
|
|
|
|
#ifndef LOOP_ANALYSIS
|
|
|
|
|
#define LOOP_ANALYSIS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
LOOP_ANALYSIS("no-op-loop", NoOpLoopAnalysis())
|
|
|
|
|
#undef LOOP_ANALYSIS
|
|
|
|
|
|
|
|
|
|
#ifndef LOOP_PASS
|
|
|
|
|
#define LOOP_PASS(NAME, CREATE_PASS)
|
|
|
|
|
#endif
|
|
|
|
|
LOOP_PASS("invalidate<all>", InvalidateAllAnalysesPass())
|
2016-05-04 06:02:31 +08:00
|
|
|
LOOP_PASS("rotate", LoopRotatePass())
|
2016-02-25 15:23:08 +08:00
|
|
|
LOOP_PASS("no-op-loop", NoOpLoopPass())
|
|
|
|
|
LOOP_PASS("print", PrintLoopPass(dbgs()))
|
2016-05-04 05:47:32 +08:00
|
|
|
LOOP_PASS("simplify-cfg", LoopSimplifyCFGPass())
|
2016-06-06 02:01:19 +08:00
|
|
|
LOOP_PASS("indvars", IndVarSimplifyPass())
|
2016-02-25 15:23:08 +08:00
|
|
|
#undef LOOP_PASS
|