maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Other/new-pass-manager.ll

456 lines
26 KiB
LLVM
Raw Normal View History

[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
; This test is essentially doing very basic things with the opt tool and the
; new pass manager pipeline. It will be used to flesh out the feature
; completeness of the opt tool when the new pass manager is engaged. The tests
; may not be useful once it becomes the default or may get spread out into other
; files, but for now this is just going to step the new process through its
; paces.
[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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
; RUN: -passes=no-op-module %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PASS
[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 18:27:39 +08:00
; CHECK-MODULE-PASS: 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 19:13:56 +08:00
; CHECK-MODULE-PASS-NEXT: 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 18:27:39 +08:00
; CHECK-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
; RUN: -passes=no-op-cgscc %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
[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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
; RUN: -passes='cgscc(no-op-cgscc)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
[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 18:27:39 +08:00
; CHECK-CGSCC-PASS: 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 19:13:56 +08:00
; CHECK-CGSCC-PASS-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor
[PM] Loosen the regex for the proxy template name even further to cope with 'class' keywords in the template arguments and other silliness. llvm-svn: 262130
2016-02-27 19:07:16 +08:00
; CHECK-CGSCC-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
[PM] Introduce CRTP mixin base classes to help define passes and analyses in the new pass manager. These just handle really basic stuff: turning a type name into a string statically that is nice to print in logs, and getting a static unique ID for each analysis. Sadly, the format of passes in anonymous namespaces makes using their names in tests really annoying so I've customized the names of the no-op passes to keep tests sane to read. This is the first of a few simplifying refactorings for the new pass manager that should reduce boilerplate and confusion. llvm-svn: 262004
2016-02-26 19:44:45 +08:00
; CHECK-CGSCC-PASS-NEXT: Running analysis: LazyCallGraphAnalysis
[PM] Improve the debugging and logging facilities of the CGSCC bits of the new pass manager. This adds operator<< overloads for the various bits of the LazyCallGraph, dump methods for use from the debugger, and debug logging using them to the CGSCC pass manager. Having this was essential for debugging the call graph update patch, and I've extracted what I could from that patch here to minimize the delta. llvm-svn: 273961
2016-06-28 07:26:08 +08:00
; CHECK-CGSCC-PASS-NEXT: Running an SCC pass across the RefSCC: [(foo)]
[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 18:27:39 +08:00
; CHECK-CGSCC-PASS-NEXT: Starting llvm::LazyCallGraph::SCC 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 19:13:56 +08:00
; CHECK-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
[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 18:27:39 +08:00
; CHECK-CGSCC-PASS-NEXT: Finished llvm::LazyCallGraph::SCC pass manager run
; CHECK-CGSCC-PASS-NEXT: Finished llvm::Module pass manager run
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
; RUN: -passes=no-op-function %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
[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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
; RUN: -passes='function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
[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 18:27:39 +08:00
; CHECK-FUNCTION-PASS: 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 19:13:56 +08:00
; CHECK-FUNCTION-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
[PM] Loosen the regex for the proxy template name even further to cope with 'class' keywords in the template arguments and other silliness. llvm-svn: 262130
2016-02-27 19:07:16 +08:00
; CHECK-FUNCTION-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
[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 18:27:39 +08:00
; CHECK-FUNCTION-PASS-NEXT: 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 19:13:56 +08:00
; CHECK-FUNCTION-PASS-NEXT: 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 18:27:39 +08:00
; CHECK-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-FUNCTION-PASS-NEXT: Finished llvm::Module pass manager run
[PM] Simplify how we parse the outer layer of the pass pipeline text and remove an extra, redundant pass manager wrapping every run. I had kept seeing these when manually testing, but it was getting really annoying and was going to cause problems with overly eager invalidation. The root cause was an overly complex and unnecessary pile of code for parsing the outer layer of the pass pipeline. We can instead delegate most of this to the recursive pipeline parsing. I've added some somewhat more basic and precise tests to catch this. llvm-svn: 225253
2015-01-06 16:37:58 +08:00
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
; RUN: opt -disable-output -debug-pass-manager -passes=print %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PRINT
[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 18:27:39 +08:00
; CHECK-MODULE-PRINT: 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 19:13:56 +08:00
; CHECK-MODULE-PRINT: Running pass: VerifierPass
; CHECK-MODULE-PRINT: Running pass: PrintModulePass
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
; CHECK-MODULE-PRINT: ModuleID
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-MODULE-PRINT: define void @foo(i1 %x)
[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 19:13:56 +08:00
; CHECK-MODULE-PRINT: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-MODULE-PRINT: Finished llvm::Module pass manager run
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='print,verify' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-VERIFY
[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 18:27:39 +08:00
; CHECK-MODULE-VERIFY: 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 19:13:56 +08:00
; CHECK-MODULE-VERIFY: Running pass: PrintModulePass
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
; CHECK-MODULE-VERIFY: ModuleID
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-MODULE-VERIFY: define void @foo(i1 %x)
[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 19:13:56 +08:00
; CHECK-MODULE-VERIFY: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-MODULE-VERIFY: Finished llvm::Module pass manager run
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
; RUN: opt -disable-output -debug-pass-manager -passes='function(print)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PRINT
[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 18:27:39 +08:00
; CHECK-FUNCTION-PRINT: 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 19:13:56 +08:00
; CHECK-FUNCTION-PRINT: Running pass: VerifierPass
; CHECK-FUNCTION-PRINT: Running pass: ModuleToFunctionPassAdaptor
[PM] Loosen the regex for the proxy template name even further to cope with 'class' keywords in the template arguments and other silliness. llvm-svn: 262130
2016-02-27 19:07:16 +08:00
; CHECK-FUNCTION-PRINT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
[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 18:27:39 +08:00
; CHECK-FUNCTION-PRINT: 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 19:13:56 +08:00
; CHECK-FUNCTION-PRINT: Running pass: PrintFunctionPass
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
; CHECK-FUNCTION-PRINT-NOT: ModuleID
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-FUNCTION-PRINT: define void @foo(i1 %x)
[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 18:27:39 +08:00
; CHECK-FUNCTION-PRINT: 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 19:13:56 +08:00
; CHECK-FUNCTION-PRINT: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-FUNCTION-PRINT: Finished llvm::Module pass manager run
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='function(print,verify)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-VERIFY
[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 18:27:39 +08:00
; CHECK-FUNCTION-VERIFY: Starting llvm::Module pass manager run
; CHECK-FUNCTION-VERIFY: 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 19:13:56 +08:00
; CHECK-FUNCTION-VERIFY: Running pass: PrintFunctionPass
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
; CHECK-FUNCTION-VERIFY-NOT: ModuleID
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-FUNCTION-VERIFY: define void @foo(i1 %x)
[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 19:13:56 +08:00
; CHECK-FUNCTION-VERIFY: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-FUNCTION-VERIFY: Finished llvm::Function pass manager run
; CHECK-FUNCTION-VERIFY: Finished llvm::Module pass manager run
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 08:08:53 +08:00
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
; RUN: opt -S -o - -passes='no-op-module,no-op-module' %s \
; RUN: | FileCheck %s --check-prefix=CHECK-NOOP
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-NOOP: define void @foo(i1 %x) {
; CHECK-NOOP: entry:
; CHECK-NOOP: br i1 %x, label %loop, label %exit
; CHECK-NOOP: loop:
; CHECK-NOOP: br label %loop
; CHECK-NOOP: exit:
[PM] Wire up support for printing assembly output from the opt command. This lets us round-trip IR in the expected manner with the opt tool. llvm-svn: 199075
2014-01-13 13:16:45 +08:00
; CHECK-NOOP: ret void
; CHECK-NOOP: }
[PM] Wire up support for writing bitcode with new PM. This moves the old pass creation functionality to its own header and updates the callers of that routine. Then it adds a new PM supporting bitcode writer to the header file, and wires that up in the opt tool. A test is added that round-trips code into bitcode and back out using the new pass manager. llvm-svn: 199078
2014-01-13 15:38:24 +08:00
; Round trip through bitcode.
; RUN: opt -f -o - -passes='no-op-module,no-op-module' %s \
; RUN: | llvm-dis \
; RUN: | FileCheck %s --check-prefix=CHECK-NOOP
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; RUN: opt -disable-output -debug-pass-manager -verify-each -passes='no-op-module,function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-VERIFY-EACH
[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 18:27:39 +08:00
; CHECK-VERIFY-EACH: 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 19:13:56 +08:00
; CHECK-VERIFY-EACH: Running pass: VerifierPass
; CHECK-VERIFY-EACH: Running pass: NoOpModulePass
; CHECK-VERIFY-EACH: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-VERIFY-EACH: 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 19:13:56 +08:00
; CHECK-VERIFY-EACH: Running pass: NoOpFunctionPass
; CHECK-VERIFY-EACH: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-VERIFY-EACH: 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 19:13:56 +08:00
; CHECK-VERIFY-EACH: Running pass: VerifierPass
[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 18:27:39 +08:00
; CHECK-VERIFY-EACH: Finished llvm::Module pass manager run
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='no-op-module,function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-NO-VERIFY
[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 18:27:39 +08:00
; CHECK-NO-VERIFY: Starting llvm::Module pass manager run
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; CHECK-NO-VERIFY-NOT: VerifierPass
[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 19:13:56 +08:00
; CHECK-NO-VERIFY: Running pass: NoOpModulePass
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; CHECK-NO-VERIFY-NOT: VerifierPass
[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 18:27:39 +08:00
; CHECK-NO-VERIFY: 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 19:13:56 +08:00
; CHECK-NO-VERIFY: Running pass: NoOpFunctionPass
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; CHECK-NO-VERIFY-NOT: VerifierPass
[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 18:27:39 +08:00
; CHECK-NO-VERIFY: Finished llvm::Function pass manager run
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08:00
; CHECK-NO-VERIFY-NOT: VerifierPass
[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 18:27:39 +08:00
; CHECK-NO-VERIFY: Finished llvm::Module pass manager run
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. llvm-svn: 199646
2014-01-20 19:34:08 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a collection of no-op analysis passes and switch the new pass manager tests to use them and be significantly more comprehensive. This, naturally, uncovered a bug where the CGSCC pass manager wasn't printing analyses when they were run. The only remaining core manipulator is I think an invalidate pass similar to the require pass. That'll be next. =] llvm-svn: 225240
2015-01-06 10:50:06 +08:00
; RUN: -passes='require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-ANALYSES
[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 18:27:39 +08:00
; CHECK-ANALYSES: 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 19:13:56 +08:00
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-ANALYSES: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-ANALYSES: Starting llvm::LazyCallGraph::SCC 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 19:13:56 +08:00
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-ANALYSES: Running analysis: NoOpCGSCCAnalysis
[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 18:27:39 +08:00
; CHECK-ANALYSES: 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 19:13:56 +08:00
; CHECK-ANALYSES: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-ANALYSES: Running analysis: NoOpFunctionAnalysis
[PM] Add names and debug logging for analysis passes to the new pass manager. This starts to allow us to test analyses more easily, but it's really only the beginning. Some of the code here is still untestable without manual changes to create analysis passes, but I wanted to factor it into a small of chunks as possible. Next up in order to be able to test things are, in no particular order: - No-op analyses passes so we don't have to use real ones to exercise the pass maneger itself. - Automatic way of generating dummy passes that require an analysis be run, including a variant that calls a 'print' method on a pass to make it even easier to print out the results of an analysis. - Dummy passes that invalidate all analyses for their IR unit so we can test invalidation and re-runs. - Automatic way to print each analysis pass as it is re-run. - Automatic but optional verification of analysis passes everywhere possible. I'm not claiming I'll get to all of these immediately, but that's what is in the pipeline at some stage. I'm fleshing out exactly what I need and what to prioritize by working on converting analyses and then trying to test the conversion. =] llvm-svn: 225162
2015-01-05 20:21:44 +08:00
[PM] Don't run the machinery of invalidating all the analysis passes when all are being preserved. We want to short-circuit this for a couple of reasons. One, I don't really want passes to grow a dependency on actually receiving their invalidate call when they've been preserved. I'm thinking about removing this entirely. But more importantly, preserving everything is likely to be the common case in a lot of scenarios, and it would be really good to bypass all of the invalidation and preservation machinery there. Avoiding calling N opaque functions to try to invalidate things that are by definition still valid seems important. =] This wasn't really inpsired by much other than seeing the spam in the logging for analyses, but it seems better ot get it checked in rather than forgetting about it. llvm-svn: 225163
2015-01-05 20:32:11 +08:00
; Make sure no-op passes that preserve all analyses don't even try to do any
; analysis invalidation.
[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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a collection of no-op analysis passes and switch the new pass manager tests to use them and be significantly more comprehensive. This, naturally, uncovered a bug where the CGSCC pass manager wasn't printing analyses when they were run. The only remaining core manipulator is I think an invalidate pass similar to the require pass. That'll be next. =] llvm-svn: 225240
2015-01-06 10:50:06 +08:00
; RUN: -passes='require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>))' %s 2>&1 \
[PM] Don't run the machinery of invalidating all the analysis passes when all are being preserved. We want to short-circuit this for a couple of reasons. One, I don't really want passes to grow a dependency on actually receiving their invalidate call when they've been preserved. I'm thinking about removing this entirely. But more importantly, preserving everything is likely to be the common case in a lot of scenarios, and it would be really good to bypass all of the invalidation and preservation machinery there. Avoiding calling N opaque functions to try to invalidate things that are by definition still valid seems important. =] This wasn't really inpsired by much other than seeing the spam in the logging for analyses, but it seems better ot get it checked in rather than forgetting about it. llvm-svn: 225163
2015-01-05 20:32:11 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-NO-OP-INVALIDATION
[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 18:27:39 +08:00
; CHECK-NO-OP-INVALIDATION: Starting llvm::Module pass manager run
[PM] Don't run the machinery of invalidating all the analysis passes when all are being preserved. We want to short-circuit this for a couple of reasons. One, I don't really want passes to grow a dependency on actually receiving their invalidate call when they've been preserved. I'm thinking about removing this entirely. But more importantly, preserving everything is likely to be the common case in a lot of scenarios, and it would be really good to bypass all of the invalidation and preservation machinery there. Avoiding calling N opaque functions to try to invalidate things that are by definition still valid seems important. =] This wasn't really inpsired by much other than seeing the spam in the logging for analyses, but it seems better ot get it checked in rather than forgetting about it. llvm-svn: 225163
2015-01-05 20:32:11 +08:00
; CHECK-NO-OP-INVALIDATION-NOT: Invalidating all non-preserved analyses
[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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='require<no-op-module>,require<no-op-module>,require<no-op-module>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS-NOT: Running analysis: NoOpModuleAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='require<no-op-module>,invalidate<no-op-module>,require<no-op-module>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Invalidating analysis: NoOpModuleAnalysis
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running analysis: NoOpModuleAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='cgscc(require<no-op-cgscc>,require<no-op-cgscc>,require<no-op-cgscc>)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS-NOT: Running analysis: NoOpCGSCCAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='cgscc(require<no-op-cgscc>,invalidate<no-op-cgscc>,require<no-op-cgscc>)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Invalidating analysis: NoOpCGSCCAnalysis
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running analysis: NoOpCGSCCAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='function(require<no-op-function>,require<no-op-function>,require<no-op-function>)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS-NOT: Running analysis: NoOpFunctionAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -debug-pass-manager \
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08:00
; RUN: -passes='function(require<no-op-function>,invalidate<no-op-function>,require<no-op-function>)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS
[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 18:27:39 +08:00
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: 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 19:13:56 +08:00
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Invalidating analysis: NoOpFunctionAnalysis
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running analysis: NoOpFunctionAnalysis
[PM] Add a utility pass template that synthesizes the invalidation of a specific analysis result. This is quite handy to test things, and will also likely be very useful for debugging issues. You could narrow down pass validation failures by walking these invalidate pass runs up and down the pass pipeline, etc. I've added support to the pass pipeline parsing to be able to create one of these for any analysis pass desired. Just adding this class uncovered one latent bug where the AnalysisManager CRTP base class had a hard-coded Module type rather than using IRUnitT. I've also added tests for invalidation and caching of analyses in a basic way across all the pass managers. These in turn uncovered two more bugs where we failed to correctly invalidate an analysis -- its results were invalidated but the key for re-running the pass was never cleared and so it was never re-run. Quite nasty. I'm very glad to debug this here rather than with a full system. Also, yes, the naming here is horrid. I'm going to update some of the names to be slightly less awful shortly. But really, I've no "good" ideas for naming. I'll be satisfied if I can get it to "not bad". llvm-svn: 225246
2015-01-06 12:49:44 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Fix a pretty nasty bug where the new pass manager would invalidate passes too many time. I think this is actually the issue that someone raised with me at the developer's meeting and in an email, but that we never really got to the bottom of. Having all the testing utilities made it much easier to dig down and uncover the core issue. When a pass manager is running many passes over a single function, we need it to invalidate the analyses between each run so that they can be re-computed as needed. We also need to track the intersection of preserved higher-level analyses across all the passes that we run (for example, if there is one module analysis which all the function analyses preserve, we want to track that and propagate it). Unfortunately, this interacted poorly with any enclosing pass adaptor between two IR units. It would see the intersection of preserved analyses, and need to invalidate any other analyses, but some of the un-preserved analyses might have already been invalidated *and recomputed*! We would fail to propagate the fact that the analysis had already been invalidated. The solution to this struck me as really strange at first, but the more I thought about it, the more natural it seemed. After a nice discussion with Duncan about it on IRC, it seemed even nicer. The idea is that invalidating an analysis *causes* it to be preserved! Preserving the lack of result is trivial. If it is recomputed, great. Until something *else* invalidates it again, we're good. The consequence of this is that the invalidate methods on the analysis manager which operate over many passes now consume their PreservedAnalyses object, update it to "preserve" every analysis pass to which it delivers an invalidation (regardless of whether the pass chooses to be removed, or handles the invalidation itself by updating itself). Then we return this augmented set from the invalidate routine, letting the pass manager take the result and use the intersection of *that* across each pass run to compute the final preserved set. This accounts for all the places where the early invalidation of an analysis has already "preserved" it for a future run. I've beefed up the testing and adjusted the assertions to show that we no longer repeatedly invalidate or compute the analyses across nested pass managers. llvm-svn: 225333
2015-01-07 09:58:35 +08:00
; RUN: -passes='require<no-op-module>,module(require<no-op-module>,function(require<no-op-function>,invalidate<all>,require<no-op-function>),require<no-op-module>),require<no-op-module>' %s 2>&1 \
[PM] Introduce a utility pass that preserves no analyses. Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
2015-01-06 17:06:35 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-INVALIDATE-ALL
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: 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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: 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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-NOT: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: 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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Running analysis: NoOpFunctionAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: InvalidateAllAnalysesPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Invalidating analysis: NoOpFunctionAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Running analysis: NoOpFunctionAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: Finished llvm::Function pass manager run
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Invalidating analysis: NoOpModuleAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: Finished llvm::Module pass manager run
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-NOT: Invalidating analysis: NoOpModuleAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-NOT: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL: Finished llvm::Module pass manager run
[PM] Fix a pretty nasty bug where the new pass manager would invalidate passes too many time. I think this is actually the issue that someone raised with me at the developer's meeting and in an email, but that we never really got to the bottom of. Having all the testing utilities made it much easier to dig down and uncover the core issue. When a pass manager is running many passes over a single function, we need it to invalidate the analyses between each run so that they can be re-computed as needed. We also need to track the intersection of preserved higher-level analyses across all the passes that we run (for example, if there is one module analysis which all the function analyses preserve, we want to track that and propagate it). Unfortunately, this interacted poorly with any enclosing pass adaptor between two IR units. It would see the intersection of preserved analyses, and need to invalidate any other analyses, but some of the un-preserved analyses might have already been invalidated *and recomputed*! We would fail to propagate the fact that the analysis had already been invalidated. The solution to this struck me as really strange at first, but the more I thought about it, the more natural it seemed. After a nice discussion with Duncan about it on IRC, it seemed even nicer. The idea is that invalidating an analysis *causes* it to be preserved! Preserving the lack of result is trivial. If it is recomputed, great. Until something *else* invalidates it again, we're good. The consequence of this is that the invalidate methods on the analysis manager which operate over many passes now consume their PreservedAnalyses object, update it to "preserve" every analysis pass to which it delivers an invalidation (regardless of whether the pass chooses to be removed, or handles the invalidation itself by updating itself). Then we return this augmented set from the invalidate routine, letting the pass manager take the result and use the intersection of *that* across each pass run to compute the final preserved set. This accounts for all the places where the early invalidation of an analysis has already "preserved" it for a future run. I've beefed up the testing and adjusted the assertions to show that we no longer repeatedly invalidate or compute the analyses across nested pass managers. llvm-svn: 225333
2015-01-07 09:58:35 +08: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-14 06:45:13 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
[PM] Fix a pretty nasty bug where the new pass manager would invalidate passes too many time. I think this is actually the issue that someone raised with me at the developer's meeting and in an email, but that we never really got to the bottom of. Having all the testing utilities made it much easier to dig down and uncover the core issue. When a pass manager is running many passes over a single function, we need it to invalidate the analyses between each run so that they can be re-computed as needed. We also need to track the intersection of preserved higher-level analyses across all the passes that we run (for example, if there is one module analysis which all the function analyses preserve, we want to track that and propagate it). Unfortunately, this interacted poorly with any enclosing pass adaptor between two IR units. It would see the intersection of preserved analyses, and need to invalidate any other analyses, but some of the un-preserved analyses might have already been invalidated *and recomputed*! We would fail to propagate the fact that the analysis had already been invalidated. The solution to this struck me as really strange at first, but the more I thought about it, the more natural it seemed. After a nice discussion with Duncan about it on IRC, it seemed even nicer. The idea is that invalidating an analysis *causes* it to be preserved! Preserving the lack of result is trivial. If it is recomputed, great. Until something *else* invalidates it again, we're good. The consequence of this is that the invalidate methods on the analysis manager which operate over many passes now consume their PreservedAnalyses object, update it to "preserve" every analysis pass to which it delivers an invalidation (regardless of whether the pass chooses to be removed, or handles the invalidation itself by updating itself). Then we return this augmented set from the invalidate routine, letting the pass manager take the result and use the intersection of *that* across each pass run to compute the final preserved set. This accounts for all the places where the early invalidation of an analysis has already "preserved" it for a future run. I've beefed up the testing and adjusted the assertions to show that we no longer repeatedly invalidate or compute the analyses across nested pass managers. llvm-svn: 225333
2015-01-07 09:58:35 +08:00
; RUN: -passes='require<no-op-module>,module(require<no-op-module>,cgscc(require<no-op-cgscc>,function(require<no-op-function>,invalidate<all>,require<no-op-function>),require<no-op-cgscc>),require<no-op-module>),require<no-op-module>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-INVALIDATE-ALL-CG
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: Starting llvm::LazyCallGraph::SCC 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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpCGSCCAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: 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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpFunctionAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: InvalidateAllAnalysesPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpFunctionAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpFunctionAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Function pass manager run
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpFunctionAnalysis
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpCGSCCAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpCGSCCAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: Finished llvm::LazyCallGraph::SCC pass manager run
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG-NOT: Invalidating analysis: NoOpCGSCCAnalysis
; CHECK-INVALIDATE-ALL-CG: Invalidating analysis: NoOpModuleAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Module pass manager run
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG-NOT: Invalidating analysis: NoOpModuleAnalysis
[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 19:13:56 +08:00
; CHECK-INVALIDATE-ALL-CG: Running pass: RequireAnalysisPass
[PM] Fold all three analysis managers into a single AnalysisManager template. This consolidates three copies of nearly the same core logic. It adds "complexity" to the ModuleAnalysisManager in that it makes it possible to share a ModuleAnalysisManager across multiple modules... But it does so by deleting *all of the code*, so I'm OK with that. This will naturally make fixing bugs in this code much simpler, etc. The only down side here is that we have to use 'typename' and 'this->' in various places, and the implementation is lifted into the header. I'll take that for the code size reduction. The convenient names are still typedef-ed and used throughout so that users can largely ignore this aspect of the implementation. The follow-up change to this will do the exact same refactoring for the PassManagers. =D It turns out that the interesting different code is almost entirely in the adaptors. At the end, that should be essentially all that is left. llvm-svn: 225757
2015-01-13 10:51:47 +08:00
; CHECK-INVALIDATE-ALL-CG-NOT: Running analysis: NoOpModuleAnalysis
[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 18:27:39 +08:00
; CHECK-INVALIDATE-ALL-CG: Finished llvm::Module pass manager run
[PM] Introduce a utility pass that preserves no analyses. Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
2015-01-06 17:06:35 +08:00
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 19:39:46 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<targetlibinfo>,invalidate<all>,require<targetlibinfo>' \
; RUN: | FileCheck %s --check-prefix=CHECK-TLI
[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 18:27:39 +08:00
; CHECK-TLI: Starting llvm::Module pass manager run
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 19:39:46 +08:00
; CHECK-TLI: Running pass: RequireAnalysisPass
; CHECK-TLI: Running analysis: TargetLibraryAnalysis
; CHECK-TLI: Running pass: InvalidateAllAnalysesPass
; CHECK-TLI-NOT: Invalidating analysis: TargetLibraryAnalysis
; CHECK-TLI: Running pass: RequireAnalysisPass
; CHECK-TLI-NOT: Running analysis: TargetLibraryAnalysis
[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 18:27:39 +08:00
; CHECK-TLI: Finished llvm::Module pass manager run
[PM] Port TargetLibraryInfo to the new pass manager, provided by the TargetLibraryAnalysis pass. There are actually no direct tests of this already in the tree. I've added the most basic test that the pass manager bits themselves work, and the TLI object produced will be tested by an upcoming patches as they port passes which rely on TLI. This is starting to point out the awkwardness of the invalidate API -- it seems poorly fitting on the *result* object. I suspect I will change it to live on the analysis instead, but that's not for this change, and I'd rather have a few more passes ported in order to have more experience with how this plays out. I believe there is only one more analysis required in order to start porting instcombine. =] llvm-svn: 226160
2015-01-15 19:39:46 +08:00
[PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
2015-02-01 18:11:22 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<targetir>,invalidate<all>,require<targetir>' \
; RUN: | FileCheck %s --check-prefix=CHECK-TIRA
[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 18:27:39 +08:00
; CHECK-TIRA: Starting llvm::Module pass manager run
[PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
2015-02-01 18:11:22 +08:00
; CHECK-TIRA: Running pass: RequireAnalysisPass
; CHECK-TIRA: Running analysis: TargetIRAnalysis
; CHECK-TIRA: Running pass: InvalidateAllAnalysesPass
; CHECK-TIRA-NOT: Invalidating analysis: TargetIRAnalysis
; CHECK-TIRA: Running pass: RequireAnalysisPass
; CHECK-TIRA-NOT: Running analysis: TargetIRAnalysis
[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 18:27:39 +08:00
; CHECK-TIRA: Finished llvm::Module pass manager run
[PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
2015-02-01 18:11:22 +08:00
[PM] Teach the module-to-function adaptor to not run function passes over declarations. This is both quite unproductive and causes things to crash, for example domtree would just assert. I've added a declaration and a domtree run to the basic high-level tests for the new pass manager. llvm-svn: 227724
2015-02-01 18:47:25 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<domtree>' \
; RUN: | FileCheck %s --check-prefix=CHECK-DT
[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 18:27:39 +08:00
; CHECK-DT: Starting llvm::Module pass manager run
[PM] Teach the module-to-function adaptor to not run function passes over declarations. This is both quite unproductive and causes things to crash, for example domtree would just assert. I've added a declaration and a domtree run to the basic high-level tests for the new pass manager. llvm-svn: 227724
2015-02-01 18:47:25 +08:00
; CHECK-DT: Running pass: RequireAnalysisPass
; CHECK-DT: Running analysis: DominatorTreeAnalysis
[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 18:27:39 +08:00
; CHECK-DT: Finished llvm::Module pass manager run
[PM] Teach the module-to-function adaptor to not run function passes over declarations. This is both quite unproductive and causes things to crash, for example domtree would just assert. I've added a declaration and a domtree run to the basic high-level tests for the new pass manager. llvm-svn: 227724
2015-02-01 18:47:25 +08:00
[PM/AA] Wire BasicAA's new pass manager class up to the pass registry. This ensures that all of the various pieces are working. The next patch will wire up commandline-driven alias analysis chain building and allow BasicAA to work with the AAManager. llvm-svn: 260838
2016-02-14 07:46:24 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<basic-aa>' \
; RUN: | FileCheck %s --check-prefix=CHECK-BASIC-AA
[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 18:27:39 +08:00
; CHECK-BASIC-AA: Starting llvm::Module pass manager run
[PM/AA] Wire BasicAA's new pass manager class up to the pass registry. This ensures that all of the various pieces are working. The next patch will wire up commandline-driven alias analysis chain building and allow BasicAA to work with the AAManager. llvm-svn: 260838
2016-02-14 07:46:24 +08:00
; CHECK-BASIC-AA: Running pass: RequireAnalysisPass
; CHECK-BASIC-AA: Running analysis: BasicAA
[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 18:27:39 +08:00
; CHECK-BASIC-AA: Finished llvm::Module pass manager run
[PM/AA] Wire BasicAA's new pass manager class up to the pass registry. This ensures that all of the various pieces are working. The next patch will wire up commandline-driven alias analysis chain building and allow BasicAA to work with the AAManager. llvm-svn: 260838
2016-02-14 07:46:24 +08:00
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering analysis passes, support pre-registering analyses, and use that to implement parsing and pre-registering a custom alias analysis pipeline. With this its possible to configure the particular alias analysis pipeline used by the AAManager from the commandline of opt. I've updated the test to show this effectively in use to build a pipeline including basic-aa as part of it. My big question for reviewers are around the APIs that are used to expose this functionality. Are folks happy with pass-by-lambda to do pass registration? Are folks happy with pre-registering analyses as a way to inject customized instances of an analysis while still using the registry for the general case? Other thoughts of course welcome. The next round of patches will be to add the rest of the alias analyses into the new pass manager and wire them up here so that they can be used from opt. This will require extending the (somewhate limited) functionality of AAManager w.r.t. module passes. Differential Revision: http://reviews.llvm.org/D17259 llvm-svn: 261197
2016-02-18 17:45:17 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<aa>' -aa-pipeline='basic-aa' \
; RUN: | FileCheck %s --check-prefix=CHECK-AA
[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 18:27:39 +08:00
; CHECK-AA: Starting llvm::Module pass manager run
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering analysis passes, support pre-registering analyses, and use that to implement parsing and pre-registering a custom alias analysis pipeline. With this its possible to configure the particular alias analysis pipeline used by the AAManager from the commandline of opt. I've updated the test to show this effectively in use to build a pipeline including basic-aa as part of it. My big question for reviewers are around the APIs that are used to expose this functionality. Are folks happy with pass-by-lambda to do pass registration? Are folks happy with pre-registering analyses as a way to inject customized instances of an analysis while still using the registry for the general case? Other thoughts of course welcome. The next round of patches will be to add the rest of the alias analyses into the new pass manager and wire them up here so that they can be used from opt. This will require extending the (somewhate limited) functionality of AAManager w.r.t. module passes. Differential Revision: http://reviews.llvm.org/D17259 llvm-svn: 261197
2016-02-18 17:45:17 +08:00
; CHECK-AA: Running pass: RequireAnalysisPass
; CHECK-AA: Running analysis: AAManager
; CHECK-AA: Running analysis: BasicAA
[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 18:27:39 +08:00
; CHECK-AA: Finished llvm::Module pass manager run
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering analysis passes, support pre-registering analyses, and use that to implement parsing and pre-registering a custom alias analysis pipeline. With this its possible to configure the particular alias analysis pipeline used by the AAManager from the commandline of opt. I've updated the test to show this effectively in use to build a pipeline including basic-aa as part of it. My big question for reviewers are around the APIs that are used to expose this functionality. Are folks happy with pass-by-lambda to do pass registration? Are folks happy with pre-registering analyses as a way to inject customized instances of an analysis while still using the registry for the general case? Other thoughts of course welcome. The next round of patches will be to add the rest of the alias analyses into the new pass manager and wire them up here so that they can be used from opt. This will require extending the (somewhate limited) functionality of AAManager w.r.t. module passes. Differential Revision: http://reviews.llvm.org/D17259 llvm-svn: 261197
2016-02-18 17:45:17 +08:00
[PM] Port memdep to the new pass manager. This is a fairly straightforward port to the new pass manager with one exception. It removes a very questionable use of releaseMemory() in the old pass to invalidate its caches between runs on a function. I don't think this is really guaranteed to be safe. I've just used the more direct port to the new PM to address this by nuking the results object each time the pass runs. While this could cause some minor malloc traffic increase, I don't expect the compile time performance hit to be noticable, and it makes the correctness and other aspects of the pass much easier to reason about. In some cases, it may make things faster by making the sets and maps smaller with better locality. Indeed, the measurements collected by Bruno (thanks!!!) show mostly compile time improvements. There is sadly very limited testing at this point as there are only two tests of memdep, and both rely on GVN. I'll be porting GVN next and that will exercise this heavily though. Differential Revision: http://reviews.llvm.org/D17962 llvm-svn: 263082
2016-03-10 08:55:30 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<memdep>' \
; RUN: | FileCheck %s --check-prefix=CHECK-MEMDEP
; CHECK-MEMDEP: Starting llvm::Module pass manager run
; CHECK-MEMDEP: Running pass: RequireAnalysisPass
; CHECK-MEMDEP: Running analysis: MemoryDependenceAnalysis
; CHECK-MEMDEP: Finished llvm::Module pass manager run
[CG] Add a new pass manager printer pass for the old call graph and actually finish wiring up the old call graph. There were bugs in the old call graph that hadn't been caught because it wasn't being tested. It wasn't being tested because it wasn't in the pipeline system and we didn't have a printing pass to run in tests. This fixes all of that. As for why I'm still keeping the old call graph alive its so that I can port GlobalsAA to the new pass manager with out forking it to work with the lazy call graph. That's clearly the right eventual design, but it seems pragmatic to defer that until its necessary. The old call graph works just fine for GlobalsAA. llvm-svn: 263104
2016-03-10 19:24:11 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager %s 2>&1 \
; RUN: -passes='require<callgraph>' \
; RUN: | FileCheck %s --check-prefix=CHECK-CALLGRAPH
; CHECK-CALLGRAPH: Starting llvm::Module pass manager run
; CHECK-CALLGRAPH: Running pass: RequireAnalysisPass
; CHECK-CALLGRAPH: Running analysis: CallGraphAnalysis
; CHECK-CALLGRAPH: Finished llvm::Module pass manager run
[PM] Wire up optimization levels and default pipeline construction APIs in the PassBuilder. These are really just stubs for now, but they give a nice API surface that Clang or other tools can start learning about and enabling for experimentation. I've also wired up parsing various synthetic module pass names to generate these set pipelines. This allows the pipelines to be combined with other passes and have their order controlled, with clear separation between the *kind* of canned pipeline, and the *level* of optimization to be used within that canned pipeline. The most interesting part of this patch is almost certainly the spec for the different optimization levels. I don't think we can ever have hard and fast rules that would make it easy to determine whether a particular optimization makes sense at a particular level -- it will always be in large part a judgement call. But hopefully this will outline the expected rationale that should be used, and the direction that the pipelines should be taken. Much of this was based on a long llvm-dev discussion I started years ago to try and crystalize the intent behind these pipelines, and now, at long long last I'm returning to the task of actually writing it down somewhere that we can cite and try to be consistent with. Differential Revision: http://reviews.llvm.org/D12826 llvm-svn: 262196
2016-02-29 06:16:03 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='default<O0>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='default<O1>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='default<O2>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='default<Os>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='default<Oz>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='lto-pre-link<O2>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O2
; CHECK-O2: Starting llvm::Module pass manager run
; CHECK-O2: Running pass: SimplifyCFGPass
; CHECK-O2: Running pass: SROA
; CHECK-O2: Running pass: EarlyCSEPass
; CHECK-O2: Running pass: LowerExpectIntrinsicPass
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='lto<O2>' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-LTO-O2
; CHECK-LTO-O2: Starting llvm::Module pass manager run
; CHECK-LTO-O2: Running pass: InstCombinePass
; CHECK-LTO-O2: Running pass: SimplifyCFGPass
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='repeat<3>(no-op-module)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-MODULE-PASS
; CHECK-REPEAT-MODULE-PASS: Starting llvm::Module pass manager run
[PM] Change the name of the repeating utility to something less overloaded (and simpler). Sean rightly pointed out in code review that we've started using "wrapper pass" as a specific part of the old pass manager, and in fact it is more applicable there. Here, we really have a pass *template* to build a repeated pass, so call it that. llvm-svn: 277689
2016-08-04 11:52:53 +08:00
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: RepeatedPass
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Starting llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Running pass: NoOpModulePass
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
; CHECK-REPEAT-MODULE-PASS-NEXT: Finished llvm::Module pass manager run
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='cgscc(repeat<3>(no-op-cgscc))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-CGSCC-PASS
; CHECK-REPEAT-CGSCC-PASS: Starting llvm::Module pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: ModuleToPostOrderCGSCCPassAdaptor
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running analysis: LazyCallGraphAnalysis
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running an SCC pass across the RefSCC: [(foo)]
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting llvm::LazyCallGraph::SCC pass manager run
[PM] Change the name of the repeating utility to something less overloaded (and simpler). Sean rightly pointed out in code review that we've started using "wrapper pass" as a specific part of the old pass manager, and in fact it is more applicable there. Here, we really have a pass *template* to build a repeated pass, so call it that. llvm-svn: 277689
2016-08-04 11:52:53 +08:00
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: RepeatedPass
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Starting llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Running pass: NoOpCGSCCPass
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::LazyCallGraph::SCC pass manager run
; CHECK-REPEAT-CGSCC-PASS-NEXT: Finished llvm::Module pass manager run
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='function(repeat<3>(no-op-function))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-FUNCTION-PASS
; CHECK-REPEAT-FUNCTION-PASS: Starting llvm::Module pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
[PM] Change the name of the repeating utility to something less overloaded (and simpler). Sean rightly pointed out in code review that we've started using "wrapper pass" as a specific part of the old pass manager, and in fact it is more applicable there. Here, we really have a pass *template* to build a repeated pass, so call it that. llvm-svn: 277689
2016-08-04 11:52:53 +08:00
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: RepeatedPass
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Starting llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Running pass: NoOpFunctionPass
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-REPEAT-FUNCTION-PASS-NEXT: Finished llvm::Module pass manager run
; RUN: opt -disable-output -disable-verify -debug-pass-manager \
; RUN: -passes='loop(repeat<3>(no-op-loop))' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-REPEAT-LOOP-PASS
; CHECK-REPEAT-LOOP-PASS: Starting llvm::Module pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: ModuleToFunctionPassAdaptor
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Function pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: FunctionToLoopPassAdaptor
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}>
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: LoopAnalysis
; CHECK-REPEAT-LOOP-PASS-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
[PM] Change the name of the repeating utility to something less overloaded (and simpler). Sean rightly pointed out in code review that we've started using "wrapper pass" as a specific part of the old pass manager, and in fact it is more applicable there. Here, we really have a pass *template* to build a repeated pass, so call it that. llvm-svn: 277689
2016-08-04 11:52:53 +08:00
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: RepeatedPass
[PM] Add a generic 'repeat N times' pass wrapper to the new pass manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
2016-08-03 15:44:48 +08:00
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Starting llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Running pass: NoOpLoopPass
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Loop pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Function pass manager run
; CHECK-REPEAT-LOOP-PASS-NEXT: Finished llvm::Module pass manager run
define void @foo(i1 %x) {
entry:
br i1 %x, label %loop, label %exit
loop:
br label %loop
exit:
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. llvm-svn: 199049
2014-01-12 20:15:39 +08:00
ret void
}
[PM] Teach the module-to-function adaptor to not run function passes over declarations. This is both quite unproductive and causes things to crash, for example domtree would just assert. I've added a declaration and a domtree run to the basic high-level tests for the new pass manager. llvm-svn: 227724
2015-02-01 18:47:25 +08:00
declare void @bar()