2014-01-12 13:15:39 +01:00
|
|
|
; This test is essentially doing very basic things with the opt tool and the
|
|
|
|
|
; new pass manager pipeline. It will be used to flesh out the feature
|
|
|
|
|
; completeness of the opt tool when the new pass manager is engaged. The tests
|
|
|
|
|
; may not be useful once it becomes the default or may get spread out into other
|
|
|
|
|
; files, but for now this is just going to step the new process through its
|
|
|
|
|
; paces.
|
|
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
2015-01-06 09:37:58 +01:00
|
|
|
; RUN: -passes=no-op-module %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PASS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-PASS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-MODULE-PASS-NEXT: Running pass: NoOpModulePass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
|
2015-01-06 09:37:58 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
2015-01-06 09:37:58 +01:00
|
|
|
; RUN: -passes=no-op-cgscc %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
2015-01-06 09:37:58 +01:00
|
|
|
; RUN: -passes='cgscc(no-op-cgscc)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-CGSCC-PASS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor
|
2016-02-27 12:07:16 +01:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
2016-02-26 12:44:45 +01:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Running analysis: LazyCallGraphAnalysis
|
2016-06-28 01:26:08 +02:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Running an SCC pass across the RefSCC: [(foo)]
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Starting CGSCC pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Finished CGSCC pass manager run
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-CGSCC-PASS-NEXT: Finished llvm::Module pass manager run
|
2015-01-06 09:37:58 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
2015-01-06 09:37:58 +01:00
|
|
|
; RUN: -passes=no-op-function %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
2015-01-06 09:37:58 +01:00
|
|
|
; RUN: -passes='function(no-op-function)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PASS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
|
2016-02-27 12:07:16 +01:00
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-FUNCTION-PASS-NEXT: Finished llvm::Module pass manager run
|
2015-01-06 09:37:58 +01:00
|
|
|
|
2014-01-12 13:15:39 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager -passes=print %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PRINT
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-PRINT: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-MODULE-PRINT: Running pass: VerifierPass
|
|
|
|
|
; CHECK-MODULE-PRINT: Running pass: PrintModulePass
|
2014-01-12 13:15:39 +01:00
|
|
|
; CHECK-MODULE-PRINT: ModuleID
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-MODULE-PRINT: define void @foo(i1 %x)
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-MODULE-PRINT: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-PRINT: Finished llvm::Module pass manager run
|
2014-01-12 13:15:39 +01:00
|
|
|
|
2015-01-05 01:08:53 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='print,verify' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-VERIFY
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-VERIFY: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-MODULE-VERIFY: Running pass: PrintModulePass
|
2015-01-05 01:08:53 +01:00
|
|
|
; CHECK-MODULE-VERIFY: ModuleID
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-MODULE-VERIFY: define void @foo(i1 %x)
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-MODULE-VERIFY: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-MODULE-VERIFY: Finished llvm::Module pass manager run
|
2015-01-05 01:08:53 +01:00
|
|
|
|
2014-01-12 13:15:39 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager -passes='function(print)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PRINT
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Running pass: VerifierPass
|
|
|
|
|
; CHECK-FUNCTION-PRINT: Running pass: ModuleToFunctionPassAdaptor
|
2016-02-27 12:07:16 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Running pass: PrintFunctionPass
|
2014-01-12 13:15:39 +01:00
|
|
|
; CHECK-FUNCTION-PRINT-NOT: ModuleID
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-FUNCTION-PRINT: define void @foo(i1 %x)
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Finished llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-PRINT: Finished llvm::Module pass manager run
|
2014-01-12 13:15:39 +01:00
|
|
|
|
2015-01-05 01:08:53 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='function(print,verify)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-VERIFY
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-VERIFY: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-FUNCTION-VERIFY: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-VERIFY: Running pass: PrintFunctionPass
|
2015-01-05 01:08:53 +01:00
|
|
|
; CHECK-FUNCTION-VERIFY-NOT: ModuleID
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-FUNCTION-VERIFY: define void @foo(i1 %x)
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-FUNCTION-VERIFY: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-FUNCTION-VERIFY: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-FUNCTION-VERIFY: Finished llvm::Module pass manager run
|
2015-01-05 01:08:53 +01:00
|
|
|
|
2014-01-13 06:16:45 +01:00
|
|
|
; RUN: opt -S -o - -passes='no-op-module,no-op-module' %s \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-NOOP
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-NOOP: define void @foo(i1 %x) {
|
|
|
|
|
; CHECK-NOOP: entry:
|
|
|
|
|
; CHECK-NOOP: br i1 %x, label %loop, label %exit
|
|
|
|
|
; CHECK-NOOP: loop:
|
|
|
|
|
; CHECK-NOOP: br label %loop
|
|
|
|
|
; CHECK-NOOP: exit:
|
2014-01-13 06:16:45 +01:00
|
|
|
; CHECK-NOOP: ret void
|
|
|
|
|
; CHECK-NOOP: }
|
|
|
|
|
|
2014-01-13 08:38:24 +01:00
|
|
|
; Round trip through bitcode.
|
|
|
|
|
; RUN: opt -f -o - -passes='no-op-module,no-op-module' %s \
|
|
|
|
|
; RUN: | llvm-dis \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-NOOP
|
|
|
|
|
|
2014-01-20 12:34:08 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager -verify-each -passes='no-op-module,function(no-op-function)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-VERIFY-EACH
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-VERIFY-EACH: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-VERIFY-EACH: Running pass: VerifierPass
|
|
|
|
|
; CHECK-VERIFY-EACH: Running pass: NoOpModulePass
|
|
|
|
|
; CHECK-VERIFY-EACH: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-VERIFY-EACH: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-VERIFY-EACH: Running pass: NoOpFunctionPass
|
|
|
|
|
; CHECK-VERIFY-EACH: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-VERIFY-EACH: Finished llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-VERIFY-EACH: Running pass: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-VERIFY-EACH: Finished llvm::Module pass manager run
|
2014-01-20 12:34:08 +01:00
|
|
|
|
|
|
|
|
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='no-op-module,function(no-op-function)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-NO-VERIFY
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-NO-VERIFY: Starting llvm::Module pass manager run
|
2014-01-20 12:34:08 +01:00
|
|
|
; CHECK-NO-VERIFY-NOT: VerifierPass
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-NO-VERIFY: Running pass: NoOpModulePass
|
2014-01-20 12:34:08 +01:00
|
|
|
; CHECK-NO-VERIFY-NOT: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-NO-VERIFY: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-NO-VERIFY: Running pass: NoOpFunctionPass
|
2014-01-20 12:34:08 +01:00
|
|
|
; CHECK-NO-VERIFY-NOT: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-NO-VERIFY: Finished llvm::Function pass manager run
|
2014-01-20 12:34:08 +01:00
|
|
|
; CHECK-NO-VERIFY-NOT: VerifierPass
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-NO-VERIFY: Finished llvm::Module pass manager run
|
2014-01-20 12:34:08 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 03:50:06 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>))' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-ANALYSES
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-ANALYSES: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-ANALYSES: Running analysis: NoOpModuleAnalysis
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-ANALYSES: Starting CGSCC pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-ANALYSES: Running analysis: NoOpCGSCCAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-ANALYSES: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-ANALYSES: Running analysis: NoOpFunctionAnalysis
|
2015-01-05 13:21:44 +01:00
|
|
|
|
2015-01-05 13:32:11 +01:00
|
|
|
; Make sure no-op passes that preserve all analyses don't even try to do any
|
|
|
|
|
; analysis invalidation.
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 03:50:06 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>))' %s 2>&1 \
|
2015-01-05 13:32:11 +01:00
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-NO-OP-INVALIDATION
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-NO-OP-INVALIDATION: Starting llvm::Module pass manager run
|
2015-01-05 13:32:11 +01:00
|
|
|
; CHECK-NO-OP-INVALIDATION-NOT: Invalidating all non-preserved analyses
|
|
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,require<no-op-module>,require<no-op-module>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
|
|
|
|
|
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS-NOT: Running analysis: NoOpModuleAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,invalidate<no-op-module>,require<no-op-module>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Invalidating analysis: NoOpModuleAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='cgscc(require<no-op-cgscc>,require<no-op-cgscc>,require<no-op-cgscc>)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
|
|
|
|
|
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS-NOT: Running analysis: NoOpCGSCCAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='cgscc(require<no-op-cgscc>,invalidate<no-op-cgscc>,require<no-op-cgscc>)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Invalidating analysis: NoOpCGSCCAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='function(require<no-op-function>,require<no-op-function>,require<no-op-function>)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
|
|
|
|
|
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS-NOT: Running analysis: NoOpFunctionAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -debug-pass-manager \
|
2015-01-06 05:49:44 +01:00
|
|
|
; RUN: -passes='function(require<no-op-function>,invalidate<no-op-function>,require<no-op-function>)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Invalidating analysis: NoOpFunctionAnalysis
|
|
|
|
|
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
|
2015-01-06 05:49:44 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
llvm-svn: 225333
2015-01-07 02:58:35 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,module(require<no-op-module>,function(require<no-op-function>,invalidate<all>,require<no-op-function>),require<no-op-module>),require<no-op-module>' %s 2>&1 \
|
2015-01-06 10:06:35 +01:00
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-INVALIDATE-ALL
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-NOT: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running analysis: NoOpFunctionAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: InvalidateAllAnalysesPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Invalidating analysis: NoOpFunctionAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running analysis: NoOpFunctionAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Finished llvm::Function pass manager run
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Invalidating analysis: NoOpModuleAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Finished llvm::Module pass manager run
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-NOT: Invalidating analysis: NoOpModuleAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-NOT: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL: Finished llvm::Module pass manager run
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
llvm-svn: 225333
2015-01-07 02:58:35 +01:00
|
|
|
|
2015-01-13 23:45:13 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
[PM] Fix a pretty nasty bug where the new pass manager would invalidate
passes too many time.
I think this is actually the issue that someone raised with me at the
developer's meeting and in an email, but that we never really got to the
bottom of. Having all the testing utilities made it much easier to dig
down and uncover the core issue.
When a pass manager is running many passes over a single function, we
need it to invalidate the analyses between each run so that they can be
re-computed as needed. We also need to track the intersection of
preserved higher-level analyses across all the passes that we run (for
example, if there is one module analysis which all the function analyses
preserve, we want to track that and propagate it). Unfortunately, this
interacted poorly with any enclosing pass adaptor between two IR units.
It would see the intersection of preserved analyses, and need to
invalidate any other analyses, but some of the un-preserved analyses
might have already been invalidated *and recomputed*! We would fail to
propagate the fact that the analysis had already been invalidated.
The solution to this struck me as really strange at first, but the more
I thought about it, the more natural it seemed. After a nice discussion
with Duncan about it on IRC, it seemed even nicer. The idea is that
invalidating an analysis *causes* it to be preserved! Preserving the
lack of result is trivial. If it is recomputed, great. Until something
*else* invalidates it again, we're good.
The consequence of this is that the invalidate methods on the analysis
manager which operate over many passes now consume their
PreservedAnalyses object, update it to "preserve" every analysis pass to
which it delivers an invalidation (regardless of whether the pass
chooses to be removed, or handles the invalidation itself by updating
itself). Then we return this augmented set from the invalidate routine,
letting the pass manager take the result and use the intersection of
*that* across each pass run to compute the final preserved set. This
accounts for all the places where the early invalidation of an analysis
has already "preserved" it for a future run.
I've beefed up the testing and adjusted the assertions to show that we
no longer repeatedly invalidate or compute the analyses across nested
pass managers.
llvm-svn: 225333
2015-01-07 02:58:35 +01:00
|
|
|
; RUN: -passes='require<no-op-module>,module(require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>,invalidate<all>,require<no-op-function>),require<no-op-cgscc>),require<no-op-module>),require<no-op-module>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-INVALIDATE-ALL-CG
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Starting llvm::Module pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpModuleAnalysis
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Starting CGSCC pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpCGSCCAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Starting llvm::Function pass manager run
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpFunctionAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: InvalidateAllAnalysesPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpFunctionAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpFunctionAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Function pass manager run
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpFunctionAnalysis
|
|
|
|
|
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpCGSCCAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpCGSCCAnalysis
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Finished CGSCC pass manager run
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG-NOT: Invalidating analysis: NoOpCGSCCAnalysis
|
|
|
|
|
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpModuleAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Module pass manager run
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG-NOT: Invalidating analysis: NoOpModuleAnalysis
|
2015-01-13 12:13:56 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
|
2015-01-13 03:51:47 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpModuleAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Module pass manager run
|
2015-01-06 10:06:35 +01:00
|
|
|
|
2015-01-15 12:39:46 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<targetlibinfo>,invalidate<all>,require<targetlibinfo>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-TLI
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-TLI: Starting llvm::Module pass manager run
|
2015-01-15 12:39:46 +01:00
|
|
|
; CHECK-TLI: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-TLI: Running analysis: TargetLibraryAnalysis
|
|
|
|
|
; CHECK-TLI: Running pass: InvalidateAllAnalysesPass
|
|
|
|
|
; CHECK-TLI-NOT: Invalidating analysis: TargetLibraryAnalysis
|
|
|
|
|
; CHECK-TLI: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-TLI-NOT: Running analysis: TargetLibraryAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-TLI: Finished llvm::Module pass manager run
|
2015-01-15 12:39:46 +01:00
|
|
|
|
2015-02-01 11:11:22 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<targetir>,invalidate<all>,require<targetir>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-TIRA
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-TIRA: Starting llvm::Module pass manager run
|
2015-02-01 11:11:22 +01:00
|
|
|
; CHECK-TIRA: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-TIRA: Running analysis: TargetIRAnalysis
|
|
|
|
|
; CHECK-TIRA: Running pass: InvalidateAllAnalysesPass
|
|
|
|
|
; CHECK-TIRA-NOT: Invalidating analysis: TargetIRAnalysis
|
|
|
|
|
; CHECK-TIRA: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-TIRA-NOT: Running analysis: TargetIRAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-TIRA: Finished llvm::Module pass manager run
|
2015-02-01 11:11:22 +01:00
|
|
|
|
2015-02-01 11:47:25 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<domtree>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-DT
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DT: Starting llvm::Module pass manager run
|
2015-02-01 11:47:25 +01:00
|
|
|
; CHECK-DT: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-DT: Running analysis: DominatorTreeAnalysis
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-DT: Finished llvm::Module pass manager run
|
2015-02-01 11:47:25 +01:00
|
|
|
|
2016-02-14 00:46:24 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<basic-aa>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-BASIC-AA
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-BASIC-AA: Starting llvm::Module pass manager run
|
2016-02-14 00:46:24 +01:00
|
|
|
; CHECK-BASIC-AA: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-BASIC-AA: Running analysis: BasicAA
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-BASIC-AA: Finished llvm::Module pass manager run
|
2016-02-14 00:46:24 +01:00
|
|
|
|
2016-02-18 10:45:17 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<aa>' -aa-pipeline='basic-aa' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-AA
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-AA: Starting llvm::Module pass manager run
|
2016-02-18 10:45:17 +01:00
|
|
|
; CHECK-AA: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-AA: Running analysis: AAManager
|
|
|
|
|
; CHECK-AA: Running analysis: BasicAA
|
2016-02-25 11:27:39 +01:00
|
|
|
; CHECK-AA: Finished llvm::Module pass manager run
|
2016-02-18 10:45:17 +01:00
|
|
|
|
2016-03-10 01:55:30 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<memdep>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-MEMDEP
|
|
|
|
|
; CHECK-MEMDEP: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-MEMDEP: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-MEMDEP: Running analysis: MemoryDependenceAnalysis
|
|
|
|
|
; CHECK-MEMDEP: Finished llvm::Module pass manager run
|
|
|
|
|
|
2016-03-10 12:24:11 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
|
|
|
|
|
; RUN: -passes='require<callgraph>' \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-CALLGRAPH
|
|
|
|
|
; CHECK-CALLGRAPH: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-CALLGRAPH: Running pass: RequireAnalysisPass
|
|
|
|
|
; CHECK-CALLGRAPH: Running analysis: CallGraphAnalysis
|
|
|
|
|
; CHECK-CALLGRAPH: Finished llvm::Module pass manager run
|
|
|
|
|
|
2016-02-28 23:16:03 +01:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='default<O0>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='default<O1>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='default<O2>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='default<Os>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='default<Oz>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='lto-pre-link<O2>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-O2
|
|
|
|
|
; CHECK-O2: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-O2: Running pass: SimplifyCFGPass
|
|
|
|
|
; CHECK-O2: Running pass: SROA
|
|
|
|
|
; CHECK-O2: Running pass: EarlyCSEPass
|
|
|
|
|
; CHECK-O2: Running pass: LowerExpectIntrinsicPass
|
|
|
|
|
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='lto<O2>' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-LTO-O2
|
|
|
|
|
; CHECK-LTO-O2: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-LTO-O2: Running pass: InstCombinePass
|
|
|
|
|
; CHECK-LTO-O2: Running pass: SimplifyCFGPass
|
|
|
|
|
|
2016-08-03 09:44:48 +02:00
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='repeat<3>(no-op-module)' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-MODULE-PASS
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS: Starting llvm::Module pass manager run
|
2016-08-04 05:52:53 +02:00
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: RepeatedPass
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='cgscc(repeat<3>(no-op-cgscc))' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-CGSCC-PASS
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running analysis: LazyCallGraphAnalysis
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running an SCC pass across the RefSCC: [(foo)]
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting CGSCC pass manager run
|
2016-08-04 05:52:53 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: RepeatedPass
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting CGSCC pass manager run
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished CGSCC pass manager run
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting CGSCC pass manager run
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished CGSCC pass manager run
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting CGSCC pass manager run
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
|
[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.
There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.
I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.
The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.
I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.
The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:
- We operate at three levels within the infrastructure: RefSCC, SCC, and
Node. In each case, we are working bottom up and so we want to
continue to iterate on the "lowest" node as the graph changes. Look at
how we iterate over nodes in an SCC running function passes as those
function passes mutate the CG. We continue to iterate on the "lowest"
SCC, which is the one that continues to contain the function just
processed.
- The call graph structure re-uses SCCs (and RefSCCs) during mutation
events for the *highest* entry in the resulting new subgraph, not the
lowest. This means that it is necessary to continually update the
current SCC or RefSCC as it shifts. This is really surprising and
subtle, and took a long time for me to work out. I actually tried
changing the call graph to provide the opposite behavior, and it
breaks *EVERYTHING*. The graph update algorithms are really deeply
tied to this particualr pattern.
- When SCCs or RefSCCs are split apart and refined and we continually
re-pin our processing to the bottom one in the subgraph, we need to
enqueue the newly formed SCCs and RefSCCs for subsequent processing.
Queuing them presents a few challenges:
1) SCCs and RefSCCs use wildly different iteration strategies at
a high level. We end up needing to converge them on worklist
approaches that can be extended in order to be able to handle the
mutations.
2) The order of the enqueuing need to remain bottom-up post-order so
that we don't get surprising order of visitation for things like
the inliner.
3) We need the worklists to have set semantics so we don't duplicate
things endlessly. We don't need a *persistent* set though because
we always keep processing the bottom node!!!! This is super, super
surprising to me and took a long time to convince myself this is
correct, but I'm pretty sure it is... Once we sink down to the
bottom node, we can't re-split out the same node in any way, and
the postorder of the current queue is fixed and unchanging.
4) We need to make sure that the "current" SCC or RefSCC actually gets
enqueued here such that we re-visit it because we continue
processing a *new*, *bottom* SCC/RefSCC.
- We also need the ability to *skip* SCCs and RefSCCs that get merged
into a larger component. We even need the ability to skip *nodes* from
an SCC that are no longer part of that SCC.
This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.
We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.
Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:
- It is really nice to do this a function at a time because that
function is likely hot in the cache. This means we want even the
function pass adaptor to support online updates to the call graph!
- To update the call graph after arbitrary function pass mutations is
quite hard. We have to build a fairly comprehensive set of
data structures and then process them. Fortunately, some of this code
is related to the code for building the cal graph in the first place.
Unfortunately, very little of it makes any sense to share because the
nature of what we're doing is so very different. I've factored out the
one part that made sense at least.
- We need to transfer these updates into the various structures for the
CGSCC pass manager. Once those were more sanely worked out, this
became relatively easier. But some of those needs necessitated changes
to the LazyCallGraph interface to make it significantly easier to
extract the changed SCCs from an update operation.
- We also need to update the CGSCC analysis manager as the shape of the
graph changes. When an SCC is merged away we need to clear analyses
associated with it from the analysis manager which we didn't have
support for in the analysis manager infrsatructure. New SCCs are easy!
But then we have the case that the original SCC has its shape changed
but remains in the call graph. There we need to *invalidate* the
analyses associated with it.
- We also need to invalidate analyses after we *finish* processing an
SCC. But the analyses we need to invalidate here are *only those for
the newly updated SCC*!!! Because we only continue processing the
bottom SCC, if we split SCCs apart the original one gets invalidated
once when its shape changes and is not processed farther so its
analyses will be correct. It is the bottom SCC which continues being
processed and needs to have the "normal" invalidation done based on
the preserved analyses set.
All of this is mostly background and context for the changes here.
Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.
Differential Revision: http://reviews.llvm.org/D21464
llvm-svn: 279618
2016-08-24 11:37:14 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished CGSCC pass manager run
|
|
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished CGSCC pass manager run
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='function(repeat<3>(no-op-function))' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-FUNCTION-PASS
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
|
2016-08-04 05:52:53 +02:00
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: RepeatedPass
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
|
|
|
|
|
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
|
|
|
|
|
; RUN: -passes='loop(repeat<3>(no-op-loop))' %s 2>&1 \
|
|
|
|
|
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-LOOP-PASS
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS: Starting llvm::Module pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: FunctionToLoopPassAdaptor
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: LoopAnalysis
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: DominatorTreeAnalysis
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
|
2016-08-04 05:52:53 +02:00
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: RepeatedPass
|
2016-08-03 09:44:48 +02:00
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Function pass manager run
|
|
|
|
|
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Module pass manager run
|
|
|
|
|
|
|
|
|
|
define void @foo(i1 %x) {
|
|
|
|
|
entry:
|
|
|
|
|
br i1 %x, label %loop, label %exit
|
|
|
|
|
|
|
|
|
|
loop:
|
|
|
|
|
br label %loop
|
|
|
|
|
|
|
|
|
|
exit:
|
2014-01-12 13:15:39 +01:00
|
|
|
ret void
|
|
|
|
|
}
|
2015-02-01 11:47:25 +01:00
|
|
|
|
|
|
|
|
declare void @bar()
|