2017-01-20 07:39:28 +08:00
|
|
|
; The IR below was crafted so as:
|
|
|
|
; 1) To have a loop, so we create a loop pass manager
|
|
|
|
; 2) To be "immutable" in the sense that no pass in the standard
|
|
|
|
; pipeline will modify it.
|
|
|
|
; Since no transformations take place, we don't expect any analyses
|
|
|
|
; to be invalidated.
|
|
|
|
; Any invalidation that shows up here is a bug, unless we started modifying
|
|
|
|
; the IR, in which case we need to make it immutable harder.
|
|
|
|
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='default<O1>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O1
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='default<O2>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='default<Os>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Os
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='default<Oz>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-Oz
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes='lto-pre-link<O2>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O2
|
|
|
|
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-peephole='no-op-function' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-PEEPHOLE
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-late-loop-optimizations='no-op-loop' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-LOOP-LATE
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-loop-optimizer-end='no-op-loop' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-LOOP-END
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-scalar-optimizer-late='no-op-function' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-SCALAR-LATE
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-cgscc-optimizer-late='no-op-cgscc' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-CGSCC-LATE
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-vectorizer-start='no-op-function' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-VECTORIZER-START
|
2018-01-23 09:25:20 +08:00
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-pipeline-start='no-op-module' \
|
|
|
|
; RUN: -passes='default<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-PIPELINE-START
|
|
|
|
; RUN: opt -disable-verify -debug-pass-manager \
|
|
|
|
; RUN: -passes-ep-pipeline-start='no-op-module' \
|
|
|
|
; RUN: -passes='lto-pre-link<O3>' -S %s 2>&1 \
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O3 \
|
|
|
|
; RUN: --check-prefix=CHECK-EP-PIPELINE-START
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O: Starting llvm::Module pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Module pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
|
2018-01-23 09:25:20 +08:00
|
|
|
; CHECK-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
|
2017-06-01 19:39:39 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Module pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: TargetIRAnalysis
|
|
|
|
; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: SROA
|
|
|
|
; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: EarlyCSEPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: LowerExpectIntrinsicPass
|
Recommit r317351 : Add CallSiteSplitting pass
This recommit r317351 after fixing a buildbot failure.
Original commit message:
Summary:
This change add a pass which tries to split a call-site to pass
more constrained arguments if its argument is predicated in the control flow
so that we can expose better context to the later passes (e.g, inliner, jump
threading, or IPA-CP based function cloning, etc.).
As of now we support two cases :
1) If a call site is dominated by an OR condition and if any of its arguments
are predicated on this OR condition, try to split the condition with more
constrained arguments. For example, in the code below, we try to split the
call site since we can predicate the argument (ptr) based on the OR condition.
Split from :
if (!ptr || c)
callee(ptr);
to :
if (!ptr)
callee(null ptr) // set the known constant value
else if (c)
callee(nonnull ptr) // set non-null attribute in the argument
2) We can also split a call-site based on constant incoming values of a PHI
For example,
from :
BB0:
%c = icmp eq i32 %i1, %i2
br i1 %c, label %BB2, label %BB1
BB1:
br label %BB2
BB2:
%p = phi i32 [ 0, %BB0 ], [ 1, %BB1 ]
call void @bar(i32 %p)
to
BB0:
%c = icmp eq i32 %i1, %i2
br i1 %c, label %BB2-split0, label %BB1
BB1:
br label %BB2-split1
BB2-split0:
call void @bar(i32 0)
br label %BB2
BB2-split1:
call void @bar(i32 1)
br label %BB2
BB2:
%p = phi i32 [ 0, %BB2-split0 ], [ 1, %BB2-split1 ]
llvm-svn: 317362
2017-11-04 04:41:16 +08:00
|
|
|
; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: IPSCCPPass
|
2017-10-25 21:40:08 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: CalledValuePropagationPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: GlobalOptPass
|
|
|
|
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PromotePass>
|
|
|
|
; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
|
|
|
|
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
2017-07-27 03:03:18 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis
|
2017-12-14 18:36:31 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: AAManager
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-PEEPHOLE-NEXT: Running pass: NoOpFunctionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
2017-02-12 13:34:04 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
|
|
|
|
; CHECK-O-NEXT: Running analysis: GlobalsAA
|
|
|
|
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
|
2017-05-05 00:58:45 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
|
|
|
|
; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor<{{.*}}LazyCallGraph{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
|
|
|
|
; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
|
|
|
|
; CHECK-O-NEXT: Starting CGSCC pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: InlinerPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy<{{.*}}LazyCallGraph{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Running pass: PostOrderFunctionAttrsPass
|
[PM/Inliner] Make the new PM's inliner process call edges across an
entire SCC before iterating on newly-introduced call edges resulting
from any inlined function bodies.
This more closely matches the behavior of the old PM's inliner. While it
wasn't really clear to me initially, this behavior is actually essential
to the inliner behaving reasonably in its current design.
Because the inliner is fundamentally a bottom-up inliner and all of its
cost modeling is designed around that it often runs into trouble within
an SCC where we don't have any meaningful bottom-up ordering to use. In
addition to potentially cyclic, infinite inlining that we block with the
inline history mechanism, it can also take seemingly simple call graph
patterns within an SCC and turn them into *insanely* large functions by
accidentally working top-down across the SCC without any of the
threshold limitations that traditional top-down inliners use.
Consider this diabolical monster.cpp file that Richard Smith came up
with to help demonstrate this issue:
```
template <int N> extern const char *str;
void g(const char *);
template <bool K, int N> void f(bool *B, bool *E) {
if (K)
g(str<N>);
if (B == E)
return;
if (*B)
f<true, N + 1>(B + 1, E);
else
f<false, N + 1>(B + 1, E);
}
template <> void f<false, MAX>(bool *B, bool *E) { return f<false, 0>(B, E); }
template <> void f<true, MAX>(bool *B, bool *E) { return f<true, 0>(B, E); }
extern bool *arr, *end;
void test() { f<false, 0>(arr, end); }
```
When compiled with '-DMAX=N' for various values of N, this will create an SCC
with a reasonably large number of functions. Previously, the inliner would try
to exhaust the inlining candidates in a single function before moving on. This,
unfortunately, turns it into a top-down inliner within the SCC. Because our
thresholds were never built for that, we will incrementally decide that it is
always worth inlining and proceed to flatten the entire SCC into that one
function.
What's worse, we'll then proceed to the next function, and do the exact same
thing except we'll skip the first function, and so on. And at each step, we'll
also make some of the constant factors larger, which is awesome.
The fix in this patch is the obvious one which makes the new PM's inliner use
the same technique used by the old PM: consider all the call edges across the
entire SCC before beginning to process call edges introduced by inlining. The
result of this is essentially to distribute the inlining across the SCC so that
every function incrementally grows toward the inline thresholds rather than
allowing the inliner to grow one of the functions vastly beyond the threshold.
The code for this is a bit awkward, but it works out OK.
We could consider in the future doing something more powerful here such as
prioritized order (via lowest cost and/or profile info) and/or a code-growth
budget per SCC. However, both of those would require really substantial work
both to design the system in a way that wouldn't break really useful
abstraction decomposition properties of the current inliner and to be tuned
across a reasonably diverse set of code and workloads. It also seems really
risky in many ways. I have only found a single real-world file that triggers
the bad behavior here and it is generated code that has a pretty pathological
pattern. I'm not worried about the inliner not doing an *awesome* job here as
long as it does *ok*. On the other hand, the cases that will be tricky to get
right in a prioritized scheme with a budget will be more common and idiomatic
for at least some frontends (C++ and Rust at least). So while these approaches
are still really interesting, I'm not in a huge rush to go after them. Staying
even closer to the existing PM's behavior, especially when this easy to do,
seems like the right short to medium term approach.
I don't really have a test case that makes sense yet... I'll try to find a
variant of the IR produced by the monster template metaprogram that is both
small enough to be sane and large enough to clearly show when we get this wrong
in the future. But I'm not confident this exists. And the behavior change here
*should* be unobservable without snooping on debug logging. So there isn't
really much to test.
The test case updates come from two incidental changes:
1) We now visit functions in an SCC in the opposite order. I don't think there
really is a "right" order here, so I just update the test cases.
2) We no longer compute some analyses when an SCC has no call instructions that
we consider for inlining.
llvm-svn: 297374
2017-03-09 19:35:40 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: FunctionAnalysisManagerCGSCCProxy
|
2017-02-10 07:54:57 +08:00
|
|
|
; CHECK-O3-NEXT: Running pass: ArgumentPromotionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: CGSCCToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: SROA
|
|
|
|
; CHECK-O-NEXT: Running pass: EarlyCSEPass
|
2017-06-28 06:25:02 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: MemorySSAAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SpeculativeExecutionPass
|
|
|
|
; CHECK-O-NEXT: Running pass: JumpThreadingPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: LazyValueAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: CorrelatedValuePropagationPass
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
|
|
|
; CHECK-O1-NEXT: Running pass: LibCallsShrinkWrapPass
|
|
|
|
; CHECK-O2-NEXT: Running pass: LibCallsShrinkWrapPass
|
|
|
|
; CHECK-O3-NEXT: Running pass: LibCallsShrinkWrapPass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-PEEPHOLE-NEXT: Running pass: NoOpFunctionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: TailCallElimPass
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Running pass: ReassociatePass
|
2017-02-10 07:54:57 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopStandardAnalysisResults{{.*}}>
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: LoopAnalysis
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LCSSAPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: ScalarEvolutionAnalysis
|
2017-02-10 16:26:58 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Starting Loop pass manager run.
|
2017-01-27 07:21:17 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopRotatePass
|
|
|
|
; CHECK-O-NEXT: Running pass: LICM
|
|
|
|
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
|
2017-05-26 09:24:11 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SimpleLoopUnswitchPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished Loop pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
|
|
|
; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopStandardAnalysisResults{{.*}}>
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: LCSSAPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Starting Loop pass manager run.
|
2017-01-27 07:21:17 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: IndVarSimplifyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopIdiomRecognizePass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-LOOP-LATE-NEXT: Running pass: NoOpLoopPass
|
2017-01-27 07:21:17 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopDeletionPass
|
2017-08-03 04:35:29 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopFullUnrollPass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-LOOP-END-NEXT: Running pass: NoOpLoopPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished Loop pass manager run.
|
|
|
|
; CHECK-Os-NEXT: Running pass: MergedLoadStoreMotionPass
|
|
|
|
; CHECK-Os-NEXT: Running pass: GVN
|
2017-04-27 08:28:03 +08:00
|
|
|
; CHECK-Os-NEXT: Running analysis: MemoryDependenceAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-Oz-NEXT: Running pass: MergedLoadStoreMotionPass
|
|
|
|
; CHECK-Oz-NEXT: Running pass: GVN
|
2017-04-27 08:28:03 +08:00
|
|
|
; CHECK-Oz-NEXT: Running analysis: MemoryDependenceAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O2-NEXT: Running pass: MergedLoadStoreMotionPass
|
|
|
|
; CHECK-O2-NEXT: Running pass: GVN
|
2017-04-27 08:28:03 +08:00
|
|
|
; CHECK-O2-NEXT: Running analysis: MemoryDependenceAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O3-NEXT: Running pass: MergedLoadStoreMotionPass
|
|
|
|
; CHECK-O3-NEXT: Running pass: GVN
|
2017-04-27 08:28:03 +08:00
|
|
|
; CHECK-O3-NEXT: Running analysis: MemoryDependenceAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: MemCpyOptPass
|
2017-04-27 08:28:03 +08:00
|
|
|
; CHECK-O1-NEXT: Running analysis: MemoryDependenceAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SCCPPass
|
|
|
|
; CHECK-O-NEXT: Running pass: BDCEPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: DemandedBitsAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-PEEPHOLE-NEXT: Running pass: NoOpFunctionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: JumpThreadingPass
|
|
|
|
; CHECK-O-NEXT: Running pass: CorrelatedValuePropagationPass
|
|
|
|
; CHECK-O-NEXT: Running pass: DSEPass
|
2017-01-27 07:21:17 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass{{.*}}>
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: LCSSAPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-SCALAR-LATE-NEXT: Running pass: NoOpFunctionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: ADCEPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: PostDominatorTreeAnalysis
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-PEEPHOLE-NEXT: Running pass: NoOpFunctionPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-CGSCC-LATE-NEXT: Running pass: NoOpCGSCCPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished CGSCC pass manager run.
|
2017-06-01 19:39:39 +08:00
|
|
|
; CHECK-O-NEXT: Finished llvm::Module pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: PassManager<{{.*}}Module{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Module pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: GlobalOptPass
|
2017-10-06 02:36:01 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: GlobalDCEPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: EliminateAvailableExternallyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
|
2017-02-12 13:34:04 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: ModuleToFunctionPassAdaptor<{{.*}}PassManager{{.*}}>
|
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: Float2IntPass
|
[PM] Enable registration of out-of-tree passes with PassBuilder
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
llvm-svn: 307532
2017-07-10 18:57:55 +08:00
|
|
|
; CHECK-EP-VECTORIZER-START-NEXT: Running pass: NoOpFunctionPass
|
2017-01-27 08:50:21 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LoopRotatePass
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: LCSSAPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopDistributePass
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopVectorizePass
|
|
|
|
; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis
|
|
|
|
; CHECK-O-NEXT: Running analysis: BranchProbabilityAnalysis
|
2017-01-27 09:32:26 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopLoadEliminationPass
|
|
|
|
; CHECK-O-NEXT: Running analysis: LoopAccessAnalysis
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
2017-12-15 06:05:20 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SLPVectorizerPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
2017-08-03 04:35:29 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopUnrollPass
|
2017-08-04 07:42:58 +08:00
|
|
|
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
|
2017-01-27 08:50:21 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: InstCombinePass
|
2017-02-10 07:54:57 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
|
2017-01-27 08:50:21 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: FunctionToLoopPassAdaptor<{{.*}}LICMPass
|
2017-12-29 16:16:06 +08:00
|
|
|
; CHECK-O-NEXT: Starting llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
|
|
|
|
; CHECK-O-NEXT: Running pass: LCSSAPass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: AlignmentFromAssumptionsPass
|
2017-01-27 08:50:21 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: LoopSinkPass
|
|
|
|
; CHECK-O-NEXT: Running pass: InstSimplifierPass
|
2017-09-09 21:38:18 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: DivRemPairsPass
|
2017-04-26 20:02:41 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
|
Add a new pass to speculate around PHI nodes with constant (integer) operands when profitable.
The core idea is to (re-)introduce some redundancies where their cost is
hidden by the cost of materializing immediates for constant operands of
PHI nodes. When the cost of the redundancies is covered by this,
avoiding materializing the immediate has numerous benefits:
1) Less register pressure
2) Potential for further folding / combining
3) Potential for more efficient instructions due to immediate operand
As a motivating example, consider the remarkably different cost on x86
of a SHL instruction with an immediate operand versus a register
operand.
This pattern turns up surprisingly frequently, but is somewhat rarely
obvious as a significant performance problem.
The pass is entirely target independent, but it does rely on the target
cost model in TTI to decide when to speculate things around the PHI
node. I've included x86-focused tests, but any target that sets up its
immediate cost model should benefit from this pass.
There is probably more that can be done in this space, but the pass
as-is is enough to get some important performance on our internal
benchmarks, and should be generally performance neutral, but help with
more extensive benchmarking is always welcome.
One awkward part is that this pass has to be scheduled after
*everything* that can eliminate these kinds of redundancies. This
includes SimplifyCFG, GVN, etc. I'm open to suggestions about better
places to put this. We could in theory make it part of the codegen pass
pipeline, but there doesn't really seem to be a good reason for that --
it isn't "lowering" in any sense and only relies on pretty standard cost
model based TTI queries, so it seems to fit well with the "optimization"
pipeline model. Still, further thoughts on the pipeline position are
welcome.
I've also only implemented this in the new pass manager. If folks are
very interested, I can try to add it to the old PM as well, but I didn't
really see much point (my use case is already switched over to the new
PM).
I've tested this pretty heavily without issue. A wide range of
benchmarks internally show no change outside the noise, and I don't see
any significant changes in SPEC either. However, the size class
computation in tcmalloc is substantially improved by this, which turns
into a 2% to 4% win on the hottest path through tcmalloc for us, so
there are definitely important cases where this is going to make
a substantial difference.
Differential revision: https://reviews.llvm.org/D37467
llvm-svn: 319164
2017-11-28 19:32:31 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: SpeculateAroundPHIsPass
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Finished llvm::Function pass manager run.
|
|
|
|
; CHECK-O-NEXT: Running pass: GlobalDCEPass
|
|
|
|
; CHECK-O-NEXT: Running pass: ConstantMergePass
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Module pass manager run.
|
2017-06-01 19:39:39 +08:00
|
|
|
; CHECK-O-NEXT: Finished llvm::Module pass manager run.
|
2017-01-20 17:30:03 +08:00
|
|
|
; CHECK-O-NEXT: Running pass: PrintModulePass
|
|
|
|
;
|
|
|
|
; Make sure we get the IR back out without changes when we print the module.
|
|
|
|
; CHECK-O-LABEL: define void @foo(i32 %n) local_unnamed_addr {
|
|
|
|
; CHECK-O-NEXT: entry:
|
|
|
|
; CHECK-O-NEXT: br label %loop
|
|
|
|
; CHECK-O: loop:
|
|
|
|
; CHECK-O-NEXT: %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
|
|
|
|
; CHECK-O-NEXT: %iv.next = add i32 %iv, 1
|
|
|
|
; CHECK-O-NEXT: tail call void @bar()
|
|
|
|
; CHECK-O-NEXT: %cmp = icmp eq i32 %iv, %n
|
|
|
|
; CHECK-O-NEXT: br i1 %cmp, label %exit, label %loop
|
|
|
|
; CHECK-O: exit:
|
|
|
|
; CHECK-O-NEXT: ret void
|
|
|
|
; CHECK-O-NEXT: }
|
|
|
|
;
|
|
|
|
; CHECK-O-NEXT: Finished llvm::Module pass manager run.
|
2017-01-20 07:39:28 +08:00
|
|
|
|
|
|
|
declare void @bar() local_unnamed_addr
|
|
|
|
|
|
|
|
define void @foo(i32 %n) local_unnamed_addr {
|
|
|
|
entry:
|
|
|
|
br label %loop
|
|
|
|
loop:
|
|
|
|
%iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
|
|
|
|
%iv.next = add i32 %iv, 1
|
|
|
|
tail call void @bar()
|
|
|
|
%cmp = icmp eq i32 %iv, %n
|
|
|
|
br i1 %cmp, label %exit, label %loop
|
|
|
|
exit:
|
|
|
|
ret void
|
|
|
|
}
|