RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
Code Issues Projects Releases Wiki Activity
912a050cc8
llvm-mirror/test/Other/pass-pipeline-parsing.ll

217 lines
11 KiB
LLVM
Raw Normal View History

[PM] Actually nest pass managers correctly when parsing the pass pipeline string. Add tests that cover this now that we have execution dumping in the pass managers. llvm-svn: 199005
2014-01-11 13:06:47 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes=no-op-module,no-op-module %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-TWO-NOOP-MP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-MP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-TWO-NOOP-MP: Running pass: NoOpModulePass
; CHECK-TWO-NOOP-MP: Running pass: NoOpModulePass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-MP: Finished llvm::Module pass manager run
[PM] Actually nest pass managers correctly when parsing the pass pipeline string. Add tests that cover this now that we have execution dumping in the pass managers. llvm-svn: 199005
2014-01-11 13:06:47 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='module(no-op-module,no-op-module)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-TWO-NOOP-MP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-TWO-NOOP-MP: Starting llvm::Module pass manager run
; CHECK-NESTED-TWO-NOOP-MP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-TWO-NOOP-MP: Running pass: NoOpModulePass
; CHECK-NESTED-TWO-NOOP-MP: Running pass: NoOpModulePass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-TWO-NOOP-MP: Finished llvm::Module pass manager run
; CHECK-NESTED-TWO-NOOP-MP: Finished llvm::Module pass manager run
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes=no-op-function,no-op-function %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-TWO-NOOP-FP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-FP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-TWO-NOOP-FP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-FP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-TWO-NOOP-FP: Running pass: NoOpFunctionPass
; CHECK-TWO-NOOP-FP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-FP: Finished llvm::Function pass manager run
; CHECK-TWO-NOOP-FP: Finished llvm::Module pass manager run
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='function(no-op-function,no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-TWO-NOOP-FP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-TWO-NOOP-FP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-TWO-NOOP-FP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-TWO-NOOP-FP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-TWO-NOOP-FP: Running pass: NoOpFunctionPass
; CHECK-NESTED-TWO-NOOP-FP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-TWO-NOOP-FP: Finished llvm::Function pass manager run
; CHECK-NESTED-TWO-NOOP-FP: Finished llvm::Module pass manager run
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-module,function(no-op-function,no-op-function),no-op-module' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MIXED-FP-AND-MP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-MIXED-FP-AND-MP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-MIXED-FP-AND-MP: Running pass: NoOpModulePass
; CHECK-MIXED-FP-AND-MP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-MIXED-FP-AND-MP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-MIXED-FP-AND-MP: Running pass: NoOpFunctionPass
; CHECK-MIXED-FP-AND-MP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-MIXED-FP-AND-MP: Finished llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-MIXED-FP-AND-MP: Running pass: NoOpModulePass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-MIXED-FP-AND-MP: Finished llvm::Module pass manager run
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
[PM] Fix a bunch of bugs I spotted by inspection when working on this code. Copious tests added to cover these cases. llvm-svn: 199039
2014-01-12 11:02:02 +01:00
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-module)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED1
; CHECK-UNBALANCED1: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='module(no-op-module))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED2
; CHECK-UNBALANCED2: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='module(no-op-module' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED3
; CHECK-UNBALANCED3: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED4
; CHECK-UNBALANCED4: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function(no-op-function))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED5
; CHECK-UNBALANCED5: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function(function(no-op-function)))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED6
; CHECK-UNBALANCED6: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function(no-op-function' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED7
; CHECK-UNBALANCED7: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function(function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED8
; CHECK-UNBALANCED8: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-module,)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED9
; CHECK-UNBALANCED9: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-function,)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-UNBALANCED10
; CHECK-UNBALANCED10: unable to parse pass pipeline description
[PM] Remove the defunt CGSCC-specific debug flag. Even before I sunk the debug flag into the opt tool this had been made obsolete by factoring the pass and analysis managers into a single set of templates that all used the core flag. No functionality changed here. llvm-svn: 225842
2015-01-13 23:45:13 +01:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
; RUN: -passes=no-op-cgscc,no-op-cgscc %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-TWO-NOOP-CG
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-CG: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-TWO-NOOP-CG: Running pass: ModuleToPostOrderCGSCCPassAdaptor
[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-TWO-NOOP-CG: Starting CGSCC pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-TWO-NOOP-CG: Running pass: NoOpCGSCCPass
; CHECK-TWO-NOOP-CG: 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-TWO-NOOP-CG: Finished CGSCC pass manager run
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-CG: Finished llvm::Module pass manager run
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
[PM] Remove the defunt CGSCC-specific debug flag. Even before I sunk the debug flag into the opt tool this had been made obsolete by factoring the pass and analysis managers into a single set of templates that all used the core flag. No functionality changed here. llvm-svn: 225842
2015-01-13 23:45:13 +01:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
; RUN: -passes='module(function(no-op-function),cgscc(no-op-cgscc,function(no-op-function),no-op-cgscc),function(no-op-function))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-MP-CG-FP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Starting llvm::Module pass manager run
; CHECK-NESTED-MP-CG-FP: Starting llvm::Module pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Finished llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: ModuleToPostOrderCGSCCPassAdaptor
[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-NESTED-MP-CG-FP: Starting CGSCC pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: NoOpCGSCCPass
; CHECK-NESTED-MP-CG-FP: Running pass: CGSCCToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Finished llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: 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-NESTED-MP-CG-FP: Finished CGSCC pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Starting llvm::Function pass manager run
[PM] Refactor the new pass manager to use a single template to implement the generic functionality of the pass managers themselves. In the new infrastructure, the pass "manager" isn't actually interesting at all. It just pipelines a single chunk of IR through N passes. We don't need to know anything about the IR or the passes to do this really and we can replace the 3 implementations of the exact same functionality with a single generic PassManager template, complementing the single generic AnalysisManager template. I've left typedefs in place to give convenient names to the various obvious instantiations of the template. With this, I think I've nuked almost all of the redundant logic in the managers, and I think the overall design is actually simpler for having single templates that clearly indicate there is no special logic here. The logging is made somewhat more annoying by this change, but I don't think the difference is worth having heavy-weight traits to help log things. llvm-svn: 225783
2015-01-13 12:13:56 +01:00
; CHECK-NESTED-MP-CG-FP: Running pass: NoOpFunctionPass
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-MP-CG-FP: Finished llvm::Function pass manager run
; CHECK-NESTED-MP-CG-FP: Finished llvm::Module pass manager run
; CHECK-NESTED-MP-CG-FP: Finished llvm::Module pass manager run
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-loop,no-op-loop' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-TWO-NOOP-LOOP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-LOOP: Starting llvm::Module pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-TWO-NOOP-LOOP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-LOOP: Starting llvm::Function pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-TWO-NOOP-LOOP: Running pass: FunctionToLoopPassAdaptor
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 07:23:21 +01:00
; CHECK-TWO-NOOP-LOOP: Starting Loop pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-TWO-NOOP-LOOP: Running pass: NoOpLoopPass
; CHECK-TWO-NOOP-LOOP: Running pass: NoOpLoopPass
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 07:23:21 +01:00
; CHECK-TWO-NOOP-LOOP: Finished Loop pass manager run
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-TWO-NOOP-LOOP: Finished llvm::Function pass manager run
; CHECK-TWO-NOOP-LOOP: Finished llvm::Module pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='module(function(loop(no-op-loop)))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-FP-LP
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='function(loop(no-op-loop))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-FP-LP
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='loop(no-op-loop)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-FP-LP
; RUN: opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-loop' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NESTED-FP-LP
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-FP-LP: Starting llvm::Module pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-NESTED-FP-LP: Running pass: ModuleToFunctionPassAdaptor
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-FP-LP: Starting llvm::Function pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-NESTED-FP-LP: Running pass: FunctionToLoopPassAdaptor
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 07:23:21 +01:00
; CHECK-NESTED-FP-LP: Starting Loop pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
; CHECK-NESTED-FP-LP: Running pass: NoOpLoopPass
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 07:23:21 +01:00
; CHECK-NESTED-FP-LP: Finished Loop pass manager run
[PM] Add the IR unit type to the pass manager's logging and make all of the testing more more explicit. This will currently fail on platforms without support for getTypeName. While an assert failure seems too harsh, I'm hoping we're OK with the regression test failure, and I'd like to find out about what platforms actually exist in this state if there are any so we can get implementations in place for them. But if we just can't fix all the host compilers to have a reasonably portable variant of getTypeName and are worried about xfailing this test on those platforms, I can add the horrible regular expression magic to make the tests support "unknown" here as well. llvm-svn: 261853
2016-02-25 11:27:39 +01:00
; CHECK-NESTED-FP-LP: Finished llvm::Function pass manager run
; CHECK-NESTED-FP-LP: Finished llvm::Module pass manager run
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
[PM] Significantly refactor the pass pipeline parsing to be easier to reason about and less error prone. The core idea is to fully parse the text without trying to identify passes or structure. This is done with a single state machine. There were various bugs in the logic around this previously that were repeated and scattered across the code. Having a single routine makes it much easier to fix and get correct. For example, this routine doesn't suffer from PR28577. Then the actual pass construction is handled using *much* easier to read code and simple loops, with particular pass manager construction sunk to live with other pass construction. This is especially nice as the pass managers *are* in fact passes. Finally, the "implicit" pass manager synthesis is done much more simply by forming "pre-parsed" structures rather than having to duplicate tons of logic. One of the bugs fixed by this was evident in the tests where we accepted a pipeline that wasn't really well formed. Another bug is PR28577 for which I have added a test case. The code is less efficient than the previous code but I'm really hoping that's not a priority. ;] Thanks to Sean for the review! Differential Revision: https://reviews.llvm.org/D22724 llvm-svn: 277561
2016-08-03 05:21:41 +02:00
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function(no-op-function)function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MISSING-COMMA1
; CHECK-MISSING-COMMA1: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='function()' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-EMPTY-INNER-PIPELINE
; CHECK-EMPTY-INNER-PIPELINE: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-module(no-op-module,whatever)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-PIPELINE-ON-MODULE-PASS
; CHECK-PIPELINE-ON-MODULE-PASS: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-cgscc(no-op-cgscc,whatever)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-PIPELINE-ON-CGSCC-PASS
; CHECK-PIPELINE-ON-CGSCC-PASS: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-function(no-op-function,whatever)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-PIPELINE-ON-FUNCTION-PASS
; CHECK-PIPELINE-ON-FUNCTION-PASS: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-loop(no-op-loop,whatever)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-PIPELINE-ON-LOOP-PASS
; CHECK-PIPELINE-ON-LOOP-PASS: unable to parse pass pipeline description
; RUN: not opt -disable-output -debug-pass-manager \
; RUN: -passes='no-op-function()' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-EMPTY-PIPELINE-ON-PASS
; CHECK-EMPTY-PIPELINE-ON-PASS: unable to parse pass pipeline description
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
define void @f() {
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 08:23:08 +01:00
entry:
br label %loop
loop:
br label %loop
[PM] Add support for parsing function passes and function pass manager nests to the opt commandline support. This also showcases the implicit-initial-manager support which will be most useful for testing. There are several bugs that I spotted by inspection here that I'll fix with test cases in subsequent commits. llvm-svn: 199038
2014-01-12 10:34:22 +01:00
}
Reference in New Issue Copy Permalink