6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-02-07 14:33:15 +00:00
Code Issues Projects Releases Wiki Activity
llvm-6502/test/Other/new-pass-manager.ll

200 lines
12 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00: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] 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225253 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-06 08:37:58 +00:00
; RUN: opt -disable-output -disable-verify -debug-pass-manager -debug-cgscc-pass-manager \
; RUN: -passes=no-op-module %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PASS
; CHECK-MODULE-PASS: Starting module pass manager
; CHECK-MODULE-PASS-NEXT: Running module pass: NoOpModulePass
; CHECK-MODULE-PASS-NEXT: Finished module pass manager run.
; RUN: opt -disable-output -disable-verify -debug-pass-manager -debug-cgscc-pass-manager \
; RUN: -passes=no-op-cgscc %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
; RUN: opt -disable-output -disable-verify -debug-pass-manager -debug-cgscc-pass-manager \
; RUN: -passes='cgscc(no-op-cgscc)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-CGSCC-PASS
; CHECK-CGSCC-PASS: Starting module pass manager
; CHECK-CGSCC-PASS-NEXT: Running module pass: ModuleToPostOrderCGSCCPassAdaptor
; CHECK-CGSCC-PASS-NEXT: Running module analysis: CGSCCAnalysisManagerModuleProxy
; CHECK-CGSCC-PASS-NEXT: Running module analysis: Lazy CallGraph Analysis
; CHECK-CGSCC-PASS-NEXT: Starting CGSCC pass manager run.
; CHECK-CGSCC-PASS-NEXT: Running CGSCC pass: NoOpCGSCCPass
; CHECK-CGSCC-PASS-NEXT: Finished CGSCC pass manager run.
; CHECK-CGSCC-PASS-NEXT: Finished module pass manager run.
; RUN: opt -disable-output -disable-verify -debug-pass-manager -debug-cgscc-pass-manager \
; RUN: -passes=no-op-function %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
; RUN: opt -disable-output -disable-verify -debug-pass-manager -debug-cgscc-pass-manager \
; RUN: -passes='function(no-op-function)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PASS
; CHECK-FUNCTION-PASS: Starting module pass manager
; CHECK-FUNCTION-PASS-NEXT: Running module pass: ModuleToFunctionPassAdaptor
; CHECK-FUNCTION-PASS-NEXT: Running module analysis: FunctionAnalysisManagerModuleProxy
; CHECK-FUNCTION-PASS-NEXT: Starting function pass manager run.
; CHECK-FUNCTION-PASS-NEXT: Running function pass: NoOpFunctionPass
; CHECK-FUNCTION-PASS-NEXT: Finished function pass manager run.
; CHECK-FUNCTION-PASS-NEXT: Finished 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; RUN: opt -disable-output -debug-pass-manager -passes=print %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-PRINT
; CHECK-MODULE-PRINT: Starting module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00:00
; CHECK-MODULE-PRINT: Running module pass: VerifierPass
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; CHECK-MODULE-PRINT: Running module pass: PrintModulePass
; CHECK-MODULE-PRINT: ModuleID
; CHECK-MODULE-PRINT: define void @foo()
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00:00
; CHECK-MODULE-PRINT: Running module pass: VerifierPass
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; CHECK-MODULE-PRINT: Finished module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225144 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 00:08:53 +00:00
; RUN: opt -disable-output -debug-pass-manager -disable-verify -passes='print,verify' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-MODULE-VERIFY
; CHECK-MODULE-VERIFY: Starting module pass manager
; CHECK-MODULE-VERIFY: Running module pass: PrintModulePass
; CHECK-MODULE-VERIFY: ModuleID
; CHECK-MODULE-VERIFY: define void @foo()
; CHECK-MODULE-VERIFY: Running module pass: VerifierPass
; CHECK-MODULE-VERIFY: Finished module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; RUN: opt -disable-output -debug-pass-manager -passes='function(print)' %s 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-FUNCTION-PRINT
; CHECK-FUNCTION-PRINT: Starting module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00:00
; CHECK-FUNCTION-PRINT: Running module pass: VerifierPass
[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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225162 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 12:21:44 +00:00
; CHECK-FUNCTION-PRINT: Running module pass: ModuleToFunctionPassAdaptor
; CHECK-FUNCTION-PRINT: Running module analysis: FunctionAnalysisManagerModuleProxy
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; CHECK-FUNCTION-PRINT: Starting function pass manager
; CHECK-FUNCTION-PRINT: Running function pass: PrintFunctionPass
; CHECK-FUNCTION-PRINT-NOT: ModuleID
; CHECK-FUNCTION-PRINT: define void @foo()
; CHECK-FUNCTION-PRINT: Finished function pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00:00
; CHECK-FUNCTION-PRINT: Running module pass: VerifierPass
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
; CHECK-FUNCTION-PRINT: Finished module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225144 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 00:08:53 +00: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
; CHECK-FUNCTION-VERIFY: Starting module pass manager
; CHECK-FUNCTION-VERIFY: Starting function pass manager
; CHECK-FUNCTION-VERIFY: Running function pass: PrintFunctionPass
; CHECK-FUNCTION-VERIFY-NOT: ModuleID
; CHECK-FUNCTION-VERIFY: define void @foo()
; CHECK-FUNCTION-VERIFY: Running function pass: VerifierPass
; CHECK-FUNCTION-VERIFY: Finished function pass manager
; CHECK-FUNCTION-VERIFY: Finished module pass manager
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199075 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-13 05:16:45 +00:00
; RUN: opt -S -o - -passes='no-op-module,no-op-module' %s \
; RUN: | FileCheck %s --check-prefix=CHECK-NOOP
; CHECK-NOOP: define void @foo() {
; 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199078 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-13 07:38:24 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00: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
; CHECK-VERIFY-EACH: Starting module pass manager
; CHECK-VERIFY-EACH: Running module pass: VerifierPass
; CHECK-VERIFY-EACH: Running module pass: NoOpModulePass
; CHECK-VERIFY-EACH: Running module pass: VerifierPass
; CHECK-VERIFY-EACH: Starting function pass manager
; CHECK-VERIFY-EACH: Running function pass: NoOpFunctionPass
; CHECK-VERIFY-EACH: Running function pass: VerifierPass
; CHECK-VERIFY-EACH: Finished function pass manager
; CHECK-VERIFY-EACH: Running module pass: VerifierPass
; CHECK-VERIFY-EACH: Finished module pass manager
; 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
; CHECK-NO-VERIFY: Starting module pass manager
; CHECK-NO-VERIFY-NOT: VerifierPass
; CHECK-NO-VERIFY: Running module pass: NoOpModulePass
; CHECK-NO-VERIFY-NOT: VerifierPass
; CHECK-NO-VERIFY: Starting function pass manager
; CHECK-NO-VERIFY: Running function pass: NoOpFunctionPass
; CHECK-NO-VERIFY-NOT: VerifierPass
; CHECK-NO-VERIFY: Finished function pass manager
; CHECK-NO-VERIFY-NOT: VerifierPass
; CHECK-NO-VERIFY: Finished module 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225240 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-06 02:50:06 +00:00
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-ANALYSES: Starting module pass manager
; CHECK-ANALYSES: Running module pass: No-op Analysis Requirement Pass
; CHECK-ANALYSES: Running module analysis: NoOpModuleAnalysis
; CHECK-ANALYSES: Starting CGSCC pass manager
; CHECK-ANALYSES: Running CGSCC pass: No-op Analysis Requirement Pass
; CHECK-ANALYSES: Running CGSCC analysis: NoOpCGSCCAnalysis
; CHECK-ANALYSES: Starting function pass manager
; CHECK-ANALYSES: Running function pass: No-op Analysis Requirement Pass
; CHECK-ANALYSES: Running function 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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225162 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 12:21:44 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225163 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 12:32:11 +00:00
; Make sure no-op passes that preserve all analyses don't even try to do any
; analysis invalidation.
[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. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225240 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-06 02:50:06 +00:00
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225163 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 12:32:11 +00:00
; RUN: | FileCheck %s --check-prefix=CHECK-NO-OP-INVALIDATION
; CHECK-NO-OP-INVALIDATION: Starting module pass manager
; CHECK-NO-OP-INVALIDATION-NOT: Invalidating all non-preserved analyses
[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". git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225246 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-06 04:49:44 +00:00
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Starting module pass manager
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running module pass: No-op Analysis Requirement Pass
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS: Running module analysis: NoOpModuleAnalysis
; CHECK-DO-CACHE-MODULE-ANALYSIS-RESULTS-NOT: Running module analysis: NoOpModuleAnalysis
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Starting module pass manager
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running module pass: No-op Analysis Requirement Pass
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running module analysis: NoOpModuleAnalysis
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Invalidating module analysis: NoOpModuleAnalysis
; CHECK-DO-INVALIDATE-MODULE-ANALYSIS-RESULTS: Running module analysis: NoOpModuleAnalysis
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Starting CGSCC pass manager
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running CGSCC pass: No-op Analysis Requirement Pass
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS: Running CGSCC analysis: NoOpCGSCCAnalysis
; CHECK-DO-CACHE-CGSCC-ANALYSIS-RESULTS-NOT: Running CGSCC analysis: NoOpCGSCCAnalysis
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Starting CGSCC pass manager
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running CGSCC pass: No-op Analysis Requirement Pass
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running CGSCC analysis: NoOpCGSCCAnalysis
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Invalidating CGSCC analysis: NoOpCGSCCAnalysis
; CHECK-DO-INVALIDATE-CGSCC-ANALYSIS-RESULTS: Running CGSCC analysis: NoOpCGSCCAnalysis
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Starting function pass manager
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running function pass: No-op Analysis Requirement Pass
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS: Running function analysis: NoOpFunctionAnalysis
; CHECK-DO-CACHE-FUNCTION-ANALYSIS-RESULTS-NOT: Running function analysis: NoOpFunctionAnalysis
; RUN: opt -disable-output -debug-pass-manager -debug-cgscc-pass-manager \
; 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
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Starting function pass manager
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running function pass: No-op Analysis Requirement Pass
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running function analysis: NoOpFunctionAnalysis
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Invalidating function analysis: NoOpFunctionAnalysis
; CHECK-DO-INVALIDATE-FUNCTION-ANALYSIS-RESULTS: Running function analysis: NoOpFunctionAnalysis
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
define void @foo() {
ret void
}
Reference in New Issue Copy Permalink