2010-10-07 04:17:38 +00:00
|
|
|
//===- llvm/InitializePasses.h -------- Initialize All 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 contains the declarations for the pass initialization routines
|
|
|
|
|
// for the entire LLVM project.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#ifndef LLVM_INITIALIZEPASSES_H
|
|
|
|
|
#define LLVM_INITIALIZEPASSES_H
|
|
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
|
|
class PassRegistry;
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeCore - Initialize all passes linked into the
|
2010-10-07 19:51:21 +00:00
|
|
|
/// TransformUtils library.
|
|
|
|
|
void initializeCore(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeTransformUtils - Initialize all passes linked into the
|
2010-10-07 17:55:47 +00:00
|
|
|
/// TransformUtils library.
|
|
|
|
|
void initializeTransformUtils(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeScalarOpts - Initialize all passes linked into the
|
2010-10-07 17:55:47 +00:00
|
|
|
/// ScalarOpts library.
|
|
|
|
|
void initializeScalarOpts(PassRegistry&);
|
|
|
|
|
|
2013-01-28 01:35:51 +00:00
|
|
|
/// initializeObjCARCOpts - Initialize all passes linked into the ObjCARCOpts
|
|
|
|
|
/// library.
|
|
|
|
|
void initializeObjCARCOpts(PassRegistry&);
|
|
|
|
|
|
2012-02-01 03:51:43 +00:00
|
|
|
/// initializeVectorization - Initialize all passes linked into the
|
|
|
|
|
/// Vectorize library.
|
|
|
|
|
void initializeVectorization(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeInstCombine - Initialize all passes linked into the
|
2015-01-20 22:44:35 +00:00
|
|
|
/// InstCombine library.
|
2010-10-07 20:04:55 +00:00
|
|
|
void initializeInstCombine(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:09:59 +00:00
|
|
|
/// initializeIPO - Initialize all passes linked into the IPO library.
|
|
|
|
|
void initializeIPO(PassRegistry&);
|
|
|
|
|
|
2010-10-07 20:17:24 +00:00
|
|
|
/// initializeInstrumentation - Initialize all passes linked into the
|
|
|
|
|
/// Instrumentation library.
|
|
|
|
|
void initializeInstrumentation(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:31:00 +00:00
|
|
|
/// initializeAnalysis - Initialize all passes linked into the Analysis library.
|
|
|
|
|
void initializeAnalysis(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:41:20 +00:00
|
|
|
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
|
|
|
|
|
void initializeCodeGen(PassRegistry&);
|
|
|
|
|
|
2016-03-08 01:38:55 +00:00
|
|
|
/// Initialize all passes linked into the GlobalISel library.
|
|
|
|
|
void initializeGlobalISel(PassRegistry &Registry);
|
|
|
|
|
|
2010-10-07 18:50:11 +00:00
|
|
|
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
|
|
|
|
|
void initializeTarget(PassRegistry&);
|
|
|
|
|
|
2016-02-20 03:46:03 +00:00
|
|
|
void initializeAAEvalLegacyPassPass(PassRegistry&);
|
2014-03-03 20:06:11 +00:00
|
|
|
void initializeAddDiscriminatorsPass(PassRegistry&);
|
2015-10-30 23:13:18 +00:00
|
|
|
void initializeADCELegacyPassPass(PassRegistry&);
|
2016-05-25 01:57:04 +00:00
|
|
|
void initializeBDCELegacyPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeAliasSetPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeAlwaysInlinerPass(PassRegistry&);
|
|
|
|
|
void initializeArgPromotionPass(PassRegistry&);
|
2014-08-21 21:50:01 +00:00
|
|
|
void initializeAtomicExpandPass(PassRegistry&);
|
2016-05-27 22:30:44 +00:00
|
|
|
void initializeSampleProfileLoaderLegacyPassPass(PassRegistry&);
|
2014-09-07 20:05:11 +00:00
|
|
|
void initializeAlignmentFromAssumptionsPass(PassRegistry&);
|
Introduce a BarrierNoop pass, a hack designed to allow *some* control
over the implicitly-formed-and-nesting CGSCC pass manager and function
pass managers, especially when using them on the opt commandline or
using extension points in the module builder. The '-barrier' opt flag
(or the pass itself) will create a no-op module pass in the pipeline,
resetting the pass manager stack, and allowing the creation of a new
pipeline of function passes or CGSCC passes to be created that is
independent from any previous pipelines.
For example, this can be used to test running two CGSCC passes in
independent CGSCC pass managers as opposed to in the same CGSCC pass
manager. It also allows us to introduce a further hack into the
PassManagerBuilder to separate the O0 pipeline extension passes from the
always-inliner's CGSCC pass manager, which they likely do not want to
participate in... At the very least none of the Sanitizer passes want
this behavior.
This fixes a bug with ASan at O0 currently, and I'll commit the ASan
test which covers this pass. I'm happy to add a test case that this pass
exists and works, but not sure how much time folks would like me to
spend adding test cases for the details of its behavior of partition
pass managers.... The whole thing is just vile, and mostly intended to
unblock ASan, so I'm hoping to rip this all out in a brave new pass
manager world.
llvm-svn: 166172
2012-10-18 08:05:46 +00:00
|
|
|
void initializeBarrierNoopPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeBasicAAWrapperPassPass(PassRegistry&);
|
2013-11-26 04:19:30 +00:00
|
|
|
void initializeCallGraphWrapperPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeBlockExtractorPassPass(PassRegistry&);
|
2015-07-14 23:40:50 +00:00
|
|
|
void initializeBlockFrequencyInfoWrapperPassPass(PassRegistry&);
|
2012-05-22 17:19:09 +00:00
|
|
|
void initializeBoundsCheckingPass(PassRegistry&);
|
2012-02-08 21:22:48 +00:00
|
|
|
void initializeBranchFolderPassPass(PassRegistry&);
|
2015-07-15 22:48:29 +00:00
|
|
|
void initializeBranchProbabilityInfoWrapperPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeBreakCriticalEdgesPass(PassRegistry&);
|
2016-03-10 11:04:40 +00:00
|
|
|
void initializeCallGraphDOTPrinterPass(PassRegistry&);
|
2016-03-10 11:08:44 +00:00
|
|
|
void initializeCallGraphPrinterLegacyPassPass(PassRegistry&);
|
2013-01-11 17:28:14 +00:00
|
|
|
void initializeCallGraphViewerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCFGOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeCFGOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeCFGPrinterPass(PassRegistry&);
|
2013-08-06 02:43:45 +00:00
|
|
|
void initializeCFGSimplifyPassPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeCFLAAWrapperPassPass(PassRegistry&);
|
2015-10-21 12:15:19 +00:00
|
|
|
void initializeExternalAAWrapperPassPass(PassRegistry&);
|
2014-11-11 21:08:02 +00:00
|
|
|
void initializeForwardControlFlowIntegrityPass(PassRegistry&);
|
2013-08-06 02:43:45 +00:00
|
|
|
void initializeFlattenCFGPassPass(PassRegistry&);
|
2013-06-19 20:18:24 +00:00
|
|
|
void initializeStructurizeCFGPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCFGViewerPass(PassRegistry&);
|
2014-01-25 02:02:55 +00:00
|
|
|
void initializeConstantHoistingPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCodeGenPreparePass(PassRegistry&);
|
2016-05-05 00:51:09 +00:00
|
|
|
void initializeConstantMergeLegacyPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeConstantPropagationPass(PassRegistry&);
|
2012-01-07 03:02:36 +00:00
|
|
|
void initializeMachineCopyPropagationPass(PassRegistry&);
|
2012-11-02 21:48:17 +00:00
|
|
|
void initializeCostModelAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCorrelatedValuePropagationPass(PassRegistry&);
|
2015-12-15 23:00:08 +00:00
|
|
|
void initializeCrossDSOCFIPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeDAEPass(PassRegistry&);
|
|
|
|
|
void initializeDAHPass(PassRegistry&);
|
2016-04-22 19:40:41 +00:00
|
|
|
void initializeDCELegacyPassPass(PassRegistry&);
|
2016-05-17 21:38:13 +00:00
|
|
|
void initializeDSELegacyPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeDeadInstEliminationPass(PassRegistry&);
|
|
|
|
|
void initializeDeadMachineInstructionElimPass(PassRegistry&);
|
2013-11-12 22:47:20 +00:00
|
|
|
void initializeDelinearizationPass(PassRegistry &);
|
dependence analysis
Patch from Preston Briggs <preston.briggs@gmail.com>.
This is an updated version of the dependence-analysis patch, including an MIV
test based on Banerjee's inequalities.
It's a fairly complete implementation of the paper
Practical Dependence Testing
Gina Goff, Ken Kennedy, and Chau-Wen Tseng
PLDI 1991
It cannot yet propagate constraints between coupled RDIV subscripts (discussed
in Section 5.3.2 of the paper).
It's organized as a FunctionPass with a single entry point that supports testing
for dependence between two instructions in a function. If there's no dependence,
it returns null. If there's a dependence, it returns a pointer to a Dependence
which can be queried about details (what kind of dependence, is it loop
independent, direction and distance vector entries, etc). I haven't included
every imaginable feature, but there's a good selection that should be adequate
for supporting many loop transformations. Of course, it can be extended as
necessary.
Included in the patch file are many test cases, commented with C code showing
the loops and array references.
llvm-svn: 165708
2012-10-11 07:32:34 +00:00
|
|
|
void initializeDependenceAnalysisPass(PassRegistry&);
|
2016-04-28 03:07:16 +00:00
|
|
|
void initializeDetectDeadLanesPass(PassRegistry&);
|
2016-05-12 22:19:39 +00:00
|
|
|
void initializeDependenceAnalysisWrapperPassPass(PassRegistry&);
|
Divergence analysis for GPU programs
Summary:
Some optimizations such as jump threading and loop unswitching can negatively
affect performance when applied to divergent branches. The divergence analysis
added in this patch conservatively estimates which branches in a GPU program
can diverge. This information can then help LLVM to run certain optimizations
selectively.
Test Plan: test/Analysis/DivergenceAnalysis/NVPTX/diverge.ll
Reviewers: resistor, hfinkel, eliben, meheff, jholewinski
Subscribers: broune, bjarke.roune, madhur13490, tstellarAMD, dberlin, echristo, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D8576
llvm-svn: 234567
2015-04-10 05:03:50 +00:00
|
|
|
void initializeDivergenceAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeDomOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeDomOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeDomPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeDomViewerPass(PassRegistry&);
|
2016-02-25 17:54:15 +00:00
|
|
|
void initializeDominanceFrontierWrapperPassPass(PassRegistry&);
|
2014-01-13 13:07:17 +00:00
|
|
|
void initializeDominatorTreeWrapperPassPass(PassRegistry&);
|
2012-07-04 00:09:54 +00:00
|
|
|
void initializeEarlyIfConverterPass(PassRegistry&);
|
2011-01-04 21:10:05 +00:00
|
|
|
void initializeEdgeBundlesPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeExpandPostRAPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeAAResultsWrapperPassPass(PassRegistry &);
|
2011-04-16 01:20:23 +00:00
|
|
|
void initializeGCOVProfilerPass(PassRegistry&);
|
2016-05-06 05:49:19 +00:00
|
|
|
void initializePGOInstrumentationGenLegacyPassPass(PassRegistry&);
|
2016-05-07 05:39:12 +00:00
|
|
|
void initializePGOInstrumentationUseLegacyPassPass(PassRegistry&);
|
2016-05-15 01:04:24 +00:00
|
|
|
void initializePGOIndirectCallPromotionLegacyPassPass(PassRegistry&);
|
2016-04-18 17:47:38 +00:00
|
|
|
void initializeInstrProfilingLegacyPassPass(PassRegistry &);
|
2011-11-16 01:35:23 +00:00
|
|
|
void initializeAddressSanitizerPass(PassRegistry&);
|
2012-11-28 10:31:36 +00:00
|
|
|
void initializeAddressSanitizerModulePass(PassRegistry&);
|
2012-11-29 09:57:20 +00:00
|
|
|
void initializeMemorySanitizerPass(PassRegistry&);
|
2012-02-13 22:50:51 +00:00
|
|
|
void initializeThreadSanitizerPass(PassRegistry&);
|
2014-11-11 22:14:37 +00:00
|
|
|
void initializeSanitizerCoverageModulePass(PassRegistry&);
|
2013-08-07 22:47:18 +00:00
|
|
|
void initializeDataFlowSanitizerPass(PassRegistry&);
|
[esan] EfficiencySanitizer instrumentation pass
Summary:
Adds an instrumentation pass for the new EfficiencySanitizer ("esan")
performance tuning family of tools. Multiple tools will be supported
within the same framework. Preliminary support for a cache fragmentation
tool is included here.
The shared instrumentation includes:
+ Turn mem{set,cpy,move} instrinsics into library calls.
+ Slowpath instrumentation of loads and stores via callouts to
the runtime library.
+ Fastpath instrumentation will be per-tool.
+ Which memory accesses to ignore will be per-tool.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, vkalintiris, pcc, silvas, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19167
llvm-svn: 267058
2016-04-21 21:30:22 +00:00
|
|
|
void initializeEfficiencySanitizerPass(PassRegistry&);
|
2013-11-22 16:58:05 +00:00
|
|
|
void initializeScalarizerPass(PassRegistry&);
|
2015-01-27 01:34:14 +00:00
|
|
|
void initializeEarlyCSELegacyPassPass(PassRegistry &);
|
2016-05-05 02:37:32 +00:00
|
|
|
void initializeEliminateAvailableExternallyLegacyPassPass(PassRegistry &);
|
2010-11-18 18:45:06 +00:00
|
|
|
void initializeExpandISelPseudosPass(PassRegistry&);
|
2015-12-27 08:13:45 +00:00
|
|
|
void initializeForceFunctionAttrsLegacyPassPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeGCMachineCodeAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeGCModuleInfoPass(PassRegistry&);
|
2016-05-18 22:55:34 +00:00
|
|
|
void initializeGuardWideningLegacyPassPass(PassRegistry&);
|
2016-03-11 08:50:55 +00:00
|
|
|
void initializeGVNLegacyPassPass(PassRegistry&);
|
2016-05-03 19:39:15 +00:00
|
|
|
void initializeGlobalDCELegacyPassPass(PassRegistry&);
|
2016-04-26 00:28:01 +00:00
|
|
|
void initializeGlobalOptLegacyPassPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeGlobalsAAWrapperPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeIPCPPass(PassRegistry&);
|
2016-05-05 21:05:36 +00:00
|
|
|
void initializeIPSCCPLegacyPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeIVUsersPass(PassRegistry&);
|
|
|
|
|
void initializeIfConverterPass(PassRegistry&);
|
2015-01-16 01:03:22 +00:00
|
|
|
void initializeInductiveRangeCheckEliminationPass(PassRegistry&);
|
2016-05-29 21:42:00 +00:00
|
|
|
void initializeIndVarSimplifyLegacyPassPass(PassRegistry&);
|
2015-12-27 08:41:34 +00:00
|
|
|
void initializeInferFunctionAttrsLegacyPassPass(PassRegistry&);
|
2013-01-21 11:39:18 +00:00
|
|
|
void initializeInlineCostAnalysisPass(PassRegistry&);
|
2015-01-20 22:44:35 +00:00
|
|
|
void initializeInstructionCombiningPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeInstCountPass(PassRegistry&);
|
|
|
|
|
void initializeInstNamerPass(PassRegistry&);
|
2016-05-19 20:08:32 +00:00
|
|
|
void initializeInterleavedAccessPass(PassRegistry &);
|
2016-04-26 20:15:52 +00:00
|
|
|
void initializeInternalizeLegacyPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeIntervalPartitionPass(PassRegistry&);
|
2016-03-08 01:38:55 +00:00
|
|
|
void initializeIRTranslatorPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeJumpThreadingPass(PassRegistry&);
|
|
|
|
|
void initializeLCSSAPass(PassRegistry&);
|
|
|
|
|
void initializeLICMPass(PassRegistry&);
|
|
|
|
|
void initializeLazyValueInfoPass(PassRegistry&);
|
|
|
|
|
void initializeLintPass(PassRegistry&);
|
2010-11-30 02:17:10 +00:00
|
|
|
void initializeLiveDebugVariablesPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLiveIntervalsPass(PassRegistry&);
|
2012-06-09 02:13:10 +00:00
|
|
|
void initializeLiveRegMatrixPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLiveStacksPass(PassRegistry&);
|
|
|
|
|
void initializeLiveVariablesPass(PassRegistry&);
|
|
|
|
|
void initializeLoaderPassPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeLocalStackSlotPassPass(PassRegistry&);
|
2016-02-22 21:41:22 +00:00
|
|
|
void initializeLoopDataPrefetchPass(PassRegistry&);
|
[LPM] Factor all of the loop analysis usage updates into a common helper
routine.
We were getting this wrong in small ways and generally being very
inconsistent about it across loop passes. Instead, let's have a common
place where we do this. One minor downside is that this will require
some analyses like SCEV in more places than they are strictly needed.
However, this seems benign as these analyses are complete no-ops, and
without this consistency we can in many cases end up with the legacy
pass manager scheduling deciding to split up a loop pass pipeline in
order to run the function analysis half-way through. It is very, very
annoying to fix these without just being very pedantic across the board.
The only loop passes I've not updated here are ones that use
AU.setPreservesAll() such as IVUsers (an analysis) and the pass printer.
They seemed less relevant.
With this patch, almost all of the problems in PR24804 around loop pass
pipelines are fixed. The one remaining issue is that we run simplify-cfg
and instcombine in the middle of the loop pass pipeline. We've recently
added some loop variants of these passes that would seem substantially
cleaner to use, but this at least gets us much closer to the previous
state. Notably, the seven loop pass managers is down to three.
I've not updated the loop passes using LoopAccessAnalysis because that
analysis hasn't been fully wired into LoopSimplify/LCSSA, and it isn't
clear that those transforms want to support those forms anyways. They
all run late anyways, so this is harmless. Similarly, LSR is left alone
because it already carefully manages its forms and doesn't need to get
fused into a single loop pass manager with a bunch of other loop passes.
LoopReroll didn't use loop simplified form previously, and I've updated
the test case to match the trivially different output.
Finally, I've also factored all the pass initialization for the passes
that use this technique as well, so that should be done regularly and
reliably.
Thanks to James for the help reviewing and thinking about this stuff,
and Ben for help thinking about it as well!
Differential Revision: http://reviews.llvm.org/D17435
llvm-svn: 261316
2016-02-19 10:45:18 +00:00
|
|
|
void initializeLoopPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopDeletionPass(PassRegistry&);
|
|
|
|
|
void initializeLoopExtractorPass(PassRegistry&);
|
2015-01-17 14:16:18 +00:00
|
|
|
void initializeLoopInfoWrapperPassPass(PassRegistry&);
|
2015-03-06 10:11:25 +00:00
|
|
|
void initializeLoopInterchangePass(PassRegistry &);
|
2011-01-03 00:25:16 +00:00
|
|
|
void initializeLoopInstSimplifyPass(PassRegistry&);
|
2016-05-03 22:02:31 +00:00
|
|
|
void initializeLoopRotateLegacyPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopSimplifyPass(PassRegistry&);
|
2016-05-03 21:47:32 +00:00
|
|
|
void initializeLoopSimplifyCFGLegacyPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopStrengthReducePass(PassRegistry&);
|
2011-10-17 17:17:43 +00:00
|
|
|
void initializeGlobalMergePass(PassRegistry&);
|
2013-11-16 23:59:05 +00:00
|
|
|
void initializeLoopRerollPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopUnrollPass(PassRegistry&);
|
|
|
|
|
void initializeLoopUnswitchPass(PassRegistry&);
|
New Loop Versioning LICM Pass
Summary:
When alias analysis is uncertain about the aliasing between any two accesses,
it will return MayAlias. This uncertainty from alias analysis restricts LICM
from proceeding further. In cases where alias analysis is uncertain we might
use loop versioning as an alternative.
Loop Versioning will create a version of the loop with aggressive aliasing
assumptions in addition to the original with conservative (default) aliasing
assumptions. The version of the loop making aggressive aliasing assumptions
will have all the memory accesses marked as no-alias. These two versions of
loop will be preceded by a memory runtime check. This runtime check consists
of bound checks for all unique memory accessed in loop, and it ensures the
lack of memory aliasing. The result of the runtime check determines which of
the loop versions is executed: If the runtime check detects any memory
aliasing, then the original loop is executed. Otherwise, the version with
aggressive aliasing assumptions is used.
The pass is off by default and can be enabled with command line option
-enable-loop-versioning-licm.
Reviewers: hfinkel, anemet, chatur01, reames
Subscribers: MatzeB, grosser, joker.eph, sanjoy, javed.absar, sbaranga,
llvm-commits
Differential Revision: http://reviews.llvm.org/D9151
llvm-svn: 259986
2016-02-06 07:47:48 +00:00
|
|
|
void initializeLoopVersioningLICMPass(PassRegistry&);
|
2010-12-26 19:32:44 +00:00
|
|
|
void initializeLoopIdiomRecognizePass(PassRegistry&);
|
2016-05-13 22:52:35 +00:00
|
|
|
void initializeLowerAtomicLegacyPassPass(PassRegistry &);
|
2015-02-20 20:30:47 +00:00
|
|
|
void initializeLowerBitSetsPass(PassRegistry&);
|
2011-07-06 18:22:43 +00:00
|
|
|
void initializeLowerExpectIntrinsicPass(PassRegistry&);
|
2016-03-31 00:18:46 +00:00
|
|
|
void initializeLowerGuardIntrinsicPass(PassRegistry&);
|
2010-10-19 17:21:58 +00:00
|
|
|
void initializeLowerIntrinsicsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLowerInvokePass(PassRegistry&);
|
|
|
|
|
void initializeLowerSwitchPass(PassRegistry&);
|
2016-01-13 23:56:37 +00:00
|
|
|
void initializeLowerEmuTLSPass(PassRegistry&);
|
2011-07-25 19:25:40 +00:00
|
|
|
void initializeMachineBlockFrequencyInfoPass(PassRegistry&);
|
Implement a block placement pass based on the branch probability and
block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:
1) It operates on the Machine-IR in the CodeGen layer. This exposes much
more (and more precise) information and opportunities. Also, the
results are more stable due to fewer transforms ocurring after the
pass runs.
2) It uses the generalized probability and frequency analyses. These can
model static heuristics, code annotation derived heuristics as well
as eventual profile loading. By basing the optimization on the
analysis interface it can work from any (or a combination) of these
inputs.
3) It uses a more aggressive algorithm, both building chains from tho
bottom up to maximize benefit, and using an SCC-based walk to layout
chains of blocks in a profitable ordering without O(N^2) iterations
which the old pass involves.
The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.
Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D
llvm-svn: 142641
2011-10-21 06:46:38 +00:00
|
|
|
void initializeMachineBlockPlacementPass(PassRegistry&);
|
2011-11-02 07:17:12 +00:00
|
|
|
void initializeMachineBlockPlacementStatsPass(PassRegistry&);
|
2011-06-16 20:22:37 +00:00
|
|
|
void initializeMachineBranchProbabilityInfoPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineCSEPass(PassRegistry&);
|
2016-04-11 13:58:45 +00:00
|
|
|
void initializeModuleSummaryIndexWrapperPassPass(PassRegistry &);
|
2015-06-15 18:44:27 +00:00
|
|
|
void initializeImplicitNullChecksPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineDominatorTreePass(PassRegistry&);
|
2014-07-12 21:59:52 +00:00
|
|
|
void initializeMachineDominanceFrontierPass(PassRegistry&);
|
2012-09-17 14:08:37 +00:00
|
|
|
void initializeMachinePostDominatorTreePass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineLICMPass(PassRegistry&);
|
|
|
|
|
void initializeMachineLoopInfoPass(PassRegistry&);
|
|
|
|
|
void initializeMachineModuleInfoPass(PassRegistry&);
|
2014-07-19 18:29:29 +00:00
|
|
|
void initializeMachineRegionInfoPassPass(PassRegistry&);
|
2012-01-17 06:55:03 +00:00
|
|
|
void initializeMachineSchedulerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineSinkingPass(PassRegistry&);
|
2012-07-26 18:38:11 +00:00
|
|
|
void initializeMachineTraceMetricsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineVerifierPassPass(PassRegistry&);
|
|
|
|
|
void initializeMemCpyOptPass(PassRegistry&);
|
|
|
|
|
void initializeMemDepPrinterPass(PassRegistry&);
|
2015-02-06 01:46:42 +00:00
|
|
|
void initializeMemDerefPrinterPass(PassRegistry&);
|
2016-03-10 00:55:30 +00:00
|
|
|
void initializeMemoryDependenceWrapperPassPass(PassRegistry&);
|
2016-06-01 21:30:40 +00:00
|
|
|
void initializeMemorySSAWrapperPassPass(PassRegistry&);
|
2014-07-18 19:13:09 +00:00
|
|
|
void initializeMergedLoadStoreMotionPass(PassRegistry &);
|
2012-09-11 02:46:18 +00:00
|
|
|
void initializeMetaRenamerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMergeFunctionsPass(PassRegistry&);
|
|
|
|
|
void initializeModuleDebugInfoPrinterPass(PassRegistry&);
|
2016-04-12 21:35:28 +00:00
|
|
|
void initializeNameAnonFunctionPass(PassRegistry &);
|
2015-04-14 04:59:22 +00:00
|
|
|
void initializeNaryReassociatePass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeNoAAPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeObjCARCAAWrapperPassPass(PassRegistry&);
|
2012-01-17 20:52:24 +00:00
|
|
|
void initializeObjCARCAPElimPass(PassRegistry&);
|
2011-06-15 23:37:01 +00:00
|
|
|
void initializeObjCARCExpandPass(PassRegistry&);
|
|
|
|
|
void initializeObjCARCContractPass(PassRegistry&);
|
|
|
|
|
void initializeObjCARCOptPass(PassRegistry&);
|
2014-11-17 02:28:27 +00:00
|
|
|
void initializePAEvalPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeOptimizePHIsPass(PassRegistry&);
|
2016-05-25 23:38:53 +00:00
|
|
|
void initializePartiallyInlineLibCallsLegacyPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializePEIPass(PassRegistry&);
|
|
|
|
|
void initializePHIEliminationPass(PassRegistry&);
|
|
|
|
|
void initializePartialInlinerPass(PassRegistry&);
|
|
|
|
|
void initializePeepholeOptimizerPass(PassRegistry&);
|
|
|
|
|
void initializePostDomOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializePostDomOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializePostDomPrinterPass(PassRegistry&);
|
|
|
|
|
void initializePostDomViewerPass(PassRegistry&);
|
2016-02-25 17:54:07 +00:00
|
|
|
void initializePostDominatorTreeWrapperPassPass(PassRegistry&);
|
2016-02-18 11:03:11 +00:00
|
|
|
void initializePostOrderFunctionAttrsLegacyPassPass(PassRegistry&);
|
2016-04-22 14:43:50 +00:00
|
|
|
void initializePostRAHazardRecognizerPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializePostRASchedulerPass(PassRegistry&);
|
2013-12-28 21:56:51 +00:00
|
|
|
void initializePostMachineSchedulerPass(PassRegistry&);
|
2016-04-22 21:18:02 +00:00
|
|
|
void initializePreISelIntrinsicLoweringPass(PassRegistry&);
|
2014-01-12 12:15:39 +00:00
|
|
|
void initializePrintFunctionPassWrapperPass(PassRegistry&);
|
|
|
|
|
void initializePrintModulePassWrapperPass(PassRegistry&);
|
2013-02-08 23:37:41 +00:00
|
|
|
void initializePrintBasicBlockPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeProcessImplicitDefsPass(PassRegistry&);
|
|
|
|
|
void initializePromotePassPass(PassRegistry&);
|
|
|
|
|
void initializePruneEHPass(PassRegistry&);
|
2016-04-26 23:39:29 +00:00
|
|
|
void initializeReassociateLegacyPassPass(PassRegistry&);
|
2016-04-05 19:06:01 +00:00
|
|
|
void initializeRegBankSelectPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeRegToMemPass(PassRegistry&);
|
2014-07-19 18:29:29 +00:00
|
|
|
void initializeRegionInfoPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeRegionOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeRegionOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeRegionPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeRegionViewerPass(PassRegistry&);
|
2016-05-31 22:38:06 +00:00
|
|
|
void initializeRenameIndependentSubregsPass(PassRegistry&);
|
2016-01-08 10:55:52 +00:00
|
|
|
void initializeReversePostOrderFunctionAttrsPass(PassRegistry&);
|
Add a pass for constructing gc.statepoint sequences w/explicit relocations
This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.relocates inserted yet, and insert them. This can be used either immediately after IR generation to perform 'early safepoint insertion' or late in the pass order to perform 'late insertion'.
This patch is setting the stage for work to continue in tree. In particular, there are known naming and style violations in the current patch. I'll try to get those resolved over the next week or so. As I touch each area to make style changes, I need to make sure we have adequate testing in place. As part of the cleanup, I will be cleaning up a collection of test cases we have out of tree and submitting them upstream. The tests included in this change are very basic and mostly to provide examples of usage.
The pass has several main subproblems it needs to address:
- First, it has identify any live pointers. In the current code, the use of address spaces to distinguish pointers to GC managed objects is hard coded, but this will become parametrizable in the near future. Note that the current change doesn't actually contain a useful liveness analysis. It was seperated into a followup change as the code wasn't ready to be shared. Instead, the current implementation just considers any dominating def of appropriate pointer type to be live.
- Second, it has to identify base pointers for each live pointer. This is a fairly straight forward data flow algorithm.
- Third, the information in the previous steps is used to actually introduce rewrites. Rather than trying to do this by hand, we simply re-purpose the code behind Mem2Reg to do this for us.
llvm-svn: 229945
2015-02-20 01:06:44 +00:00
|
|
|
void initializeRewriteStatepointsForGCPass(PassRegistry&);
|
Protection against stack-based memory corruption errors using SafeStack
This patch adds the safe stack instrumentation pass to LLVM, which separates
the program stack into a safe stack, which stores return addresses, register
spills, and local variables that are statically verified to be accessed
in a safe way, and the unsafe stack, which stores everything else. Such
separation makes it much harder for an attacker to corrupt objects on the
safe stack, including function pointers stored in spilled registers and
return addresses. You can find more information about the safe stack, as
well as other parts of or control-flow hijack protection technique in our
OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
and our project website (http://levee.epfl.ch).
The overhead of our implementation of the safe stack is very close to zero
(0.01% on the Phoronix benchmarks). This is lower than the overhead of
stack cookies, which are supported by LLVM and are commonly used today,
yet the security guarantees of the safe stack are strictly stronger than
stack cookies. In some cases, the safe stack improves performance due to
better cache locality.
Our current implementation of the safe stack is stable and robust, we
used it to recompile multiple projects on Linux including Chromium, and
we also recompiled the entire FreeBSD user-space system and more than 100
packages. We ran unit tests on the FreeBSD system and many of the packages
and observed no errors caused by the safe stack. The safe stack is also fully
binary compatible with non-instrumented code and can be applied to parts of
a program selectively.
This patch is our implementation of the safe stack on top of LLVM. The
patches make the following changes:
- Add the safestack function attribute, similar to the ssp, sspstrong and
sspreq attributes.
- Add the SafeStack instrumentation pass that applies the safe stack to all
functions that have the safestack attribute. This pass moves all unsafe local
variables to the unsafe stack with a separate stack pointer, whereas all
safe variables remain on the regular stack that is managed by LLVM as usual.
- Invoke the pass as the last stage before code generation (at the same time
the existing cookie-based stack protector pass is invoked).
- Add unit tests for the safe stack.
Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.
Differential Revision: http://reviews.llvm.org/D6094
llvm-svn: 239761
2015-06-15 21:07:11 +00:00
|
|
|
void initializeSafeStackPass(PassRegistry&);
|
2016-05-18 15:18:25 +00:00
|
|
|
void initializeSCCPLegacyPassPass(PassRegistry &);
|
2015-09-12 09:09:14 +00:00
|
|
|
void initializeSROALegacyPassPass(PassRegistry&);
|
2011-01-18 03:53:26 +00:00
|
|
|
void initializeSROA_DTPass(PassRegistry&);
|
2011-01-14 08:13:00 +00:00
|
|
|
void initializeSROA_SSAUpPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeSCEVAAWrapperPassPass(PassRegistry&);
|
[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 02:08:17 +00:00
|
|
|
void initializeScalarEvolutionWrapperPassPass(PassRegistry&);
|
[ShrinkWrap] Add (a simplified version) of shrink-wrapping.
This patch introduces a new pass that computes the safe point to insert the
prologue and epilogue of the function.
The interest is to find safe points that are cheaper than the entry and exits
blocks.
As an example and to avoid regressions to be introduce, this patch also
implements the required bits to enable the shrink-wrapping pass for AArch64.
** Context **
Currently we insert the prologue and epilogue of the method/function in the
entry and exits blocks. Although this is correct, we can do a better job when
those are not immediately required and insert them at less frequently executed
places.
The job of the shrink-wrapping pass is to identify such places.
** Motivating example **
Let us consider the following function that perform a call only in one branch of
a if:
define i32 @f(i32 %a, i32 %b) {
%tmp = alloca i32, align 4
%tmp2 = icmp slt i32 %a, %b
br i1 %tmp2, label %true, label %false
true:
store i32 %a, i32* %tmp, align 4
%tmp4 = call i32 @doSomething(i32 0, i32* %tmp)
br label %false
false:
%tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ]
ret i32 %tmp.0
}
On AArch64 this code generates (removing the cfi directives to ease
readabilities):
_f: ; @f
; BB#0:
stp x29, x30, [sp, #-16]!
mov x29, sp
sub sp, sp, #16 ; =16
cmp w0, w1
b.ge LBB0_2
; BB#1: ; %true
stur w0, [x29, #-4]
sub x1, x29, #4 ; =4
mov w0, wzr
bl _doSomething
LBB0_2: ; %false
mov sp, x29
ldp x29, x30, [sp], #16
ret
With shrink-wrapping we could generate:
_f: ; @f
; BB#0:
cmp w0, w1
b.ge LBB0_2
; BB#1: ; %true
stp x29, x30, [sp, #-16]!
mov x29, sp
sub sp, sp, #16 ; =16
stur w0, [x29, #-4]
sub x1, x29, #4 ; =4
mov w0, wzr
bl _doSomething
add sp, x29, #16 ; =16
ldp x29, x30, [sp], #16
LBB0_2: ; %false
ret
Therefore, we would pay the overhead of setting up/destroying the frame only if
we actually do the call.
** Proposed Solution **
This patch introduces a new machine pass that perform the shrink-wrapping
analysis (See the comments at the beginning of ShrinkWrap.cpp for more details).
It then stores the safe save and restore point into the MachineFrameInfo
attached to the MachineFunction.
This information is then used by the PrologEpilogInserter (PEI) to place the
related code at the right place. This pass runs right before the PEI.
Unlike the original paper of Chow from PLDI’88, this implementation of
shrink-wrapping does not use expensive data-flow analysis and does not need hack
to properly avoid frequently executed point. Instead, it relies on dominance and
loop properties.
The pass is off by default and each target can opt-in by setting the
EnableShrinkWrap boolean to true in their derived class of TargetPassConfig.
This setting can also be overwritten on the command line by using
-enable-shrink-wrap.
Before you try out the pass for your target, make sure you properly fix your
emitProlog/emitEpilog/adjustForXXX method to cope with basic blocks that are not
necessarily the entry block.
** Design Decisions **
1. ShrinkWrap is its own pass right now. It could frankly be merged into PEI but
for debugging and clarity I thought it was best to have its own file.
2. Right now, we only support one save point and one restore point. At some
point we can expand this to several save point and restore point, the impacted
component would then be:
- The pass itself: New algorithm needed.
- MachineFrameInfo: Hold a list or set of Save/Restore point instead of one
pointer.
- PEI: Should loop over the save point and restore point.
Anyhow, at least for this first iteration, I do not believe this is interesting
to support the complex cases. We should revisit that when we motivating
examples.
Differential Revision: http://reviews.llvm.org/D9210
<rdar://problem/3201744>
llvm-svn: 236507
2015-05-05 17:38:16 +00:00
|
|
|
void initializeShrinkWrapPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSimpleInlinerPass(PassRegistry&);
|
2015-10-30 23:02:38 +00:00
|
|
|
void initializeShadowStackGCLoweringPass(PassRegistry&);
|
2011-06-26 22:34:10 +00:00
|
|
|
void initializeRegisterCoalescerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSingleLoopExtractorPass(PassRegistry&);
|
2016-04-22 19:54:10 +00:00
|
|
|
void initializeSinkingLegacyPassPass(PassRegistry&);
|
2014-05-01 18:38:36 +00:00
|
|
|
void initializeSeparateConstOffsetFromGEPPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSlotIndexesPass(PassRegistry&);
|
2011-01-06 01:21:53 +00:00
|
|
|
void initializeSpillPlacementPass(PassRegistry&);
|
2015-05-15 17:54:48 +00:00
|
|
|
void initializeSpeculativeExecutionPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStackProtectorPass(PassRegistry&);
|
2012-09-06 09:17:37 +00:00
|
|
|
void initializeStackColoringPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStackSlotColoringPass(PassRegistry&);
|
Add straight-line strength reduction to LLVM
Summary:
Straight-line strength reduction (SLSR) is implemented in GCC but not yet in
LLVM. It has proven to effectively simplify statements derived from an unrolled
loop, and can potentially benefit many other cases too. For example,
LLVM unrolls
#pragma unroll
foo (int i = 0; i < 3; ++i) {
sum += foo((b + i) * s);
}
into
sum += foo(b * s);
sum += foo((b + 1) * s);
sum += foo((b + 2) * s);
However, no optimizations yet reduce the internal redundancy of the three
expressions:
b * s
(b + 1) * s
(b + 2) * s
With SLSR, LLVM can optimize these three expressions into:
t1 = b * s
t2 = t1 + s
t3 = t2 + s
This commit is only an initial step towards implementing a series of such
optimizations. I will implement more (see TODO in the file commentary) in the
near future. This optimization is enabled for the NVPTX backend for now.
However, I am more than happy to push it to the standard optimization pipeline
after more thorough performance tests.
Test Plan: test/StraightLineStrengthReduce/slsr.ll
Reviewers: eliben, HaoLiu, meheff, hfinkel, jholewinski, atrick
Reviewed By: jholewinski, atrick
Subscribers: karthikthecool, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D7310
llvm-svn: 228016
2015-02-03 19:37:06 +00:00
|
|
|
void initializeStraightLineStrengthReducePass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStripDeadDebugInfoPass(PassRegistry&);
|
2015-10-30 23:28:12 +00:00
|
|
|
void initializeStripDeadPrototypesLegacyPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStripDebugDeclarePass(PassRegistry&);
|
|
|
|
|
void initializeStripNonDebugSymbolsPass(PassRegistry&);
|
|
|
|
|
void initializeStripSymbolsPass(PassRegistry&);
|
|
|
|
|
void initializeTailCallElimPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeTailDuplicatePassPass(PassRegistry&);
|
2012-02-04 02:56:45 +00:00
|
|
|
void initializeTargetPassConfigPass(PassRegistry&);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
llvm-svn: 227669
2015-01-31 03:43:40 +00:00
|
|
|
void initializeTargetTransformInfoWrapperPassPass(PassRegistry &);
|
2015-01-15 10:41:28 +00:00
|
|
|
void initializeTargetLibraryInfoWrapperPassPass(PassRegistry &);
|
2015-01-04 12:03:27 +00:00
|
|
|
void initializeAssumptionCacheTrackerPass(PassRegistry &);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeTwoAddressInstructionPassPass(PassRegistry&);
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-09 17:55:00 +00:00
|
|
|
void initializeTypeBasedAAWrapperPassPass(PassRegistry&);
|
|
|
|
|
void initializeScopedNoAliasAAWrapperPassPass(PassRegistry&);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeUnifyFunctionExitNodesPass(PassRegistry&);
|
|
|
|
|
void initializeUnreachableBlockElimPass(PassRegistry&);
|
|
|
|
|
void initializeUnreachableMachineBlockElimPass(PassRegistry&);
|
|
|
|
|
void initializeVerifierLegacyPassPass(PassRegistry&);
|
|
|
|
|
void initializeVirtRegMapPass(PassRegistry&);
|
|
|
|
|
void initializeVirtRegRewriterPass(PassRegistry&);
|
|
|
|
|
void initializeInstSimplifierPass(PassRegistry&);
|
|
|
|
|
void initializeUnpackMachineBundlesPass(PassRegistry&);
|
|
|
|
|
void initializeFinalizeMachineBundlesPass(PassRegistry&);
|
2015-02-19 19:15:04 +00:00
|
|
|
void initializeLoopAccessAnalysisPass(PassRegistry&);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeLoopVectorizePass(PassRegistry&);
|
|
|
|
|
void initializeSLPVectorizerPass(PassRegistry&);
|
|
|
|
|
void initializeBBVectorizePass(PassRegistry&);
|
|
|
|
|
void initializeMachineFunctionPrinterPassPass(PassRegistry&);
|
2015-05-27 18:02:19 +00:00
|
|
|
void initializeMIRPrintingPassPass(PassRegistry&);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeStackMapLivenessPass(PassRegistry&);
|
2015-12-16 11:09:48 +00:00
|
|
|
void initializeLiveDebugValuesPass(PassRegistry&);
|
2014-08-03 21:35:39 +00:00
|
|
|
void initializeMachineCombinerPass(PassRegistry &);
|
2014-05-29 01:55:07 +00:00
|
|
|
void initializeLoadCombinePass(PassRegistry&);
|
2014-11-07 21:32:08 +00:00
|
|
|
void initializeRewriteSymbolsPass(PassRegistry&);
|
2015-01-29 00:41:44 +00:00
|
|
|
void initializeWinEHPreparePass(PassRegistry&);
|
2016-04-11 13:58:45 +00:00
|
|
|
void initializeWriteBitcodePassPass(PassRegistry &);
|
Add a pass for inserting safepoints into (nearly) arbitrary IR
This pass is responsible for figuring out where to place call safepoints and safepoint polls. It doesn't actually make the relocations explicit; that's the job of the RewriteStatepointsForGC pass (http://reviews.llvm.org/D6975).
Note that this code is not yet finalized. Its moving in tree for incremental development, but further cleanup is needed and will happen over the next few days. It is not yet part of the standard pass order.
Planned changes in the near future:
- I plan on restructuring the statepoint rewrite to use the functions add to the IRBuilder a while back.
- In the current pass, the function "gc.safepoint_poll" is treated specially but is not an intrinsic. I plan to make identifying the poll function a property of the GCStrategy at some point in the near future.
- As follow on patches, I will be separating a collection of test cases we have out of tree and submitting them upstream.
- It's not explicit in the code, but these two patches are introducing a new state for a statepoint which looks a lot like a patchpoint. There's no a transient form which doesn't yet have the relocations explicitly represented, but does prevent reordering of memory operations. Once this is in, I need to update actually make this explicit by reserving the 'unused' argument of the statepoint as a flag, updating the docs, and making the code explicitly check for such a thing. This wasn't really planned, but once I split the two passes - which was done for other reasons - the intermediate state fell out. Just reminds us once again that we need to merge statepoints and patchpoints at some point in the not that distant future.
Future directions planned:
- Identifying more cases where a backedge safepoint isn't required to ensure timely execution of a safepoint poll.
- Tweaking the insertion process to generate easier to optimize IR. (For example, investigating making SplitBackedge) the default.
- Adding opt-in flags for a GCStrategy to use this pass. Once done, add this pass to the actual pass ordering.
Differential Revision: http://reviews.llvm.org/D6981
llvm-svn: 228090
2015-02-04 00:37:33 +00:00
|
|
|
void initializePlaceBackedgeSafepointsImplPass(PassRegistry&);
|
|
|
|
|
void initializePlaceSafepointsPass(PassRegistry&);
|
2015-02-18 23:17:41 +00:00
|
|
|
void initializeDwarfEHPreparePass(PassRegistry&);
|
2015-03-27 10:36:57 +00:00
|
|
|
void initializeFloat2IntPass(PassRegistry&);
|
2015-05-14 12:05:18 +00:00
|
|
|
void initializeLoopDistributePass(PassRegistry&);
|
2015-07-09 21:48:40 +00:00
|
|
|
void initializeSjLjEHPreparePass(PassRegistry&);
|
2016-04-18 23:55:01 +00:00
|
|
|
void initializeDemandedBitsWrapperPassPass(PassRegistry&);
|
2015-09-17 20:45:18 +00:00
|
|
|
void initializeFuncletLayoutPass(PassRegistry &);
|
LLE 6/6: Add LoopLoadElimination pass
Summary:
The goal of this pass is to perform store-to-load forwarding across the
backedge of a loop. E.g.:
for (i)
A[i + 1] = A[i] + B[i]
=>
T = A[0]
for (i)
T = T + B[i]
A[i + 1] = T
The pass relies on loop dependence analysis via LoopAccessAnalisys to
find opportunities of loop-carried dependences with a distance of one
between a store and a load. Since it's using LoopAccessAnalysis, it was
easy to also add support for versioning away may-aliasing intervening
stores that would otherwise prevent this transformation.
This optimization is also performed by Load-PRE in GVN without the
option of multi-versioning. As was discussed with Daniel Berlin in
http://reviews.llvm.org/D9548, this is inferior to a more loop-aware
solution applied here. Hopefully, we will be able to remove some
complexity from GVN/MemorySSA as a consequence.
In the long run, we may want to extend this pass (or create a new one if
there is little overlap) to also eliminate loop-indepedent redundant
loads and store that *require* versioning due to may-aliasing
intervening stores/loads. I have some motivating cases for store
elimination. My plan right now is to wait for MemorySSA to come online
first rather than using memdep for this.
The main motiviation for this pass is the 456.hmmer loop in SPECint2006
where after distributing the original loop and vectorizing the top part,
we are left with the critical path exposed in the bottom loop. Being
able to promote the memory dependence into a register depedence (even
though the HW does perform store-to-load fowarding as well) results in a
major gain (~20%). This gain also transfers over to x86: it's
around 8-10%.
Right now the pass is off by default and can be enabled
with -enable-loop-load-elim. On the LNT testsuite, there are two
performance changes (negative number -> improvement):
1. -28% in Polybench/linear-algebra/solvers/dynprog: the length of the
critical paths is reduced
2. +2% in Polybench/stencils/adi: Unfortunately, I couldn't reproduce this
outside of LNT
The pass is scheduled after the loop vectorizer (which is after loop
distribution). The rational is to try to reuse LAA state, rather than
recomputing it. The order between LV and LLE is not critical because
normally LV does not touch scalar st->ld forwarding cases where
vectorizing would inhibit the CPU's st->ld forwarding to kick in.
LoopLoadElimination requires LAA to provide the full set of dependences
(including forward dependences). LAA is known to omit loop-independent
dependences in certain situations. The big comment before
removeDependencesFromMultipleStores explains why this should not occur
for the cases that we're interested in.
Reviewers: dberlin, hfinkel
Subscribers: junbuml, dberlin, mssimpso, rengolin, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13259
llvm-svn: 252017
2015-11-03 23:50:08 +00:00
|
|
|
void initializeLoopLoadEliminationPass(PassRegistry&);
|
2015-11-24 06:07:49 +00:00
|
|
|
void initializeFunctionImportPassPass(PassRegistry &);
|
2016-02-03 00:06:10 +00:00
|
|
|
void initializeLoopVersioningPassPass(PassRegistry &);
|
2016-02-09 22:50:34 +00:00
|
|
|
void initializeWholeProgramDevirtPass(PassRegistry &);
|
2016-04-19 05:24:47 +00:00
|
|
|
void initializePatchableFunctionPass(PassRegistry &);
|
2015-06-23 09:49:53 +00:00
|
|
|
}
|
2010-10-07 04:17:38 +00:00
|
|
|
|
|
|
|
|
#endif
|
