maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Passes/PassRegistry.def

78 lines
2.8 KiB
Modula-2
Raw Normal View History

[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
//===- PassRegistry.def - Registry of passes --------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file is used as the registry of passes that are part of the core LLVM
// libraries. This file describes both transformation passes and analyses
// Analyses are registered while transformation passes have names registered
// that can be used when providing a textual pass pipeline.
//
//===----------------------------------------------------------------------===//
// NOTE: NO INCLUDE GUARD DESIRED!
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 16:20:10 +08:00
#ifndef MODULE_ANALYSIS
#define MODULE_ANALYSIS(NAME, CREATE_PASS)
#endif
MODULE_ANALYSIS("lcg", LazyCallGraphAnalysis())
[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
MODULE_ANALYSIS("no-op-module", NoOpModuleAnalysis())
[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
MODULE_ANALYSIS("targetlibinfo", TargetLibraryAnalysis())
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 16:20:10 +08:00
#undef MODULE_ANALYSIS
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
#ifndef MODULE_PASS
#define MODULE_PASS(NAME, CREATE_PASS)
#endif
[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
MODULE_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 10:37:55 +08:00
MODULE_PASS("no-op-module", NoOpModulePass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
MODULE_PASS("print", PrintModulePass(dbgs()))
MODULE_PASS("print-cg", LazyCallGraphPrinterPass(dbgs()))
[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
MODULE_PASS("verify", VerifierPass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
#undef MODULE_PASS
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 19:12:00 +08:00
#ifndef CGSCC_ANALYSIS
#define CGSCC_ANALYSIS(NAME, CREATE_PASS)
#endif
[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
CGSCC_ANALYSIS("no-op-cgscc", NoOpCGSCCAnalysis())
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 19:12:00 +08:00
#undef CGSCC_ANALYSIS
#ifndef CGSCC_PASS
#define CGSCC_PASS(NAME, CREATE_PASS)
#endif
[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
CGSCC_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 10:37:55 +08:00
CGSCC_PASS("no-op-cgscc", NoOpCGSCCPass())
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 19:12:00 +08:00
#undef CGSCC_PASS
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 16:20:10 +08:00
#ifndef FUNCTION_ANALYSIS
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS)
#endif
[PM] Actually add the new pass manager support for the assumption cache. I had already factored this analysis specifically to enable doing this, but hadn't actually committed the necessary wiring to get at this from the new pass manager. This also nicely shows how the separate cache object can be directly managed by the new pass manager. This analysis didn't have any direct tests and so I've added a printer pass and a boring test case. I chose to print the i1 value which is being assumed rather than the call to llvm.assume as that seems much more useful for testing... but suggestions on an even better printing strategy welcome. My main goal was to make sure things actually work. =] llvm-svn: 226868
2015-01-23 05:53:09 +08:00
FUNCTION_ANALYSIS("assumptions", AssumptionAnalysis())
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 18:19:28 +08:00
FUNCTION_ANALYSIS("domtree", DominatorTreeAnalysis())
[PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysis pass and a LoopPrinterPass with the expected associated wiring. I've added a RUN line to the only test case (!!!) we have that actually prints loops. Everything seems to be working. This is somewhat exciting as this is the first analysis using another analysis to go in for the new pass manager. =D I also believe it is the last analysis necessary for porting instcombine, but of course I may yet discover more. llvm-svn: 226560
2015-01-20 18:58:50 +08:00
FUNCTION_ANALYSIS("loops", LoopAnalysis())
[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
FUNCTION_ANALYSIS("no-op-function", NoOpFunctionAnalysis())
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 10:06:09 +08:00
FUNCTION_ANALYSIS("targetlibinfo", TargetLibraryAnalysis())
[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
FUNCTION_ANALYSIS("targetir",
TM ? TM->getTargetIRAnalysis() : TargetIRAnalysis())
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 16:20:10 +08:00
#undef FUNCTION_ANALYSIS
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
#ifndef FUNCTION_PASS
#define FUNCTION_PASS(NAME, CREATE_PASS)
#endif
[PM] Port EarlyCSE to the new pass manager. I've added RUN lines both to the basic test for EarlyCSE and the target-specific test, as this serves as a nice test that the TTI layer in the new pass manager is in fact working well. llvm-svn: 227725
2015-02-01 18:51:23 +08:00
FUNCTION_PASS("early-cse", EarlyCSEPass())
[PM] Port instcombine to the new pass manager! This is exciting as this is a much more involved port. This is a complex, existing transformation pass. All of the core logic is shared between both old and new pass managers. Only the access to the analyses is separate because the actual techniques are separate. This also uses a bunch of different and interesting analyses and is the first time where we need to use an analysis across an IR layer. This also paves the way to expose instcombine utility functions. I've got a static function that implements the core pass logic over a function which might be mildly interesting, but more interesting is likely exposing a routine which just uses instructions *already in* the worklist and combines until empty. I've switched one of my favorite instcombine tests to run with both as well to make sure this keeps working. llvm-svn: 226987
2015-01-24 12:19:17 +08:00
FUNCTION_PASS("instcombine", InstCombinePass())
[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
FUNCTION_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 10:37:55 +08:00
FUNCTION_PASS("no-op-function", NoOpFunctionPass())
[PM] Port LowerExpectIntrinsic to the new pass manager. This just lifts the logic into a static helper function, sinks the legacy pass to be a trivial wrapper of that helper fuction, and adds a trivial wrapper for the new PM as well. Not much to see here. I switched a test case to run in both modes, but we have to strip the dead prototypes separately as that pass isn't in the new pass manager (yet). llvm-svn: 226999
2015-01-24 19:13:02 +08:00
FUNCTION_PASS("lower-expect", LowerExpectIntrinsicPass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
FUNCTION_PASS("print", PrintFunctionPass(dbgs()))
[PM] Actually add the new pass manager support for the assumption cache. I had already factored this analysis specifically to enable doing this, but hadn't actually committed the necessary wiring to get at this from the new pass manager. This also nicely shows how the separate cache object can be directly managed by the new pass manager. This analysis didn't have any direct tests and so I've added a printer pass and a boring test case. I chose to print the i1 value which is being assumed rather than the call to llvm.assume as that seems much more useful for testing... but suggestions on an even better printing strategy welcome. My main goal was to make sure things actually work. =] llvm-svn: 226868
2015-01-23 05:53:09 +08:00
FUNCTION_PASS("print<assumptions>", AssumptionPrinterPass(dbgs()))
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 18:19:28 +08:00
FUNCTION_PASS("print<domtree>", DominatorTreePrinterPass(dbgs()))
[PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysis pass and a LoopPrinterPass with the expected associated wiring. I've added a RUN line to the only test case (!!!) we have that actually prints loops. Everything seems to be working. This is somewhat exciting as this is the first analysis using another analysis to go in for the new pass manager. =D I also believe it is the last analysis necessary for porting instcombine, but of course I may yet discover more. llvm-svn: 226560
2015-01-20 18:58:50 +08:00
FUNCTION_PASS("print<loops>", LoopPrinterPass(dbgs()))
[PM] Port SimplifyCFG to the new pass manager. This should be sufficient to replace the initial (minor) function pass pipeline in Clang with the new pass manager. I'll probably add an (off by default) flag to do that just to ensure we can get extra testing. llvm-svn: 227726
2015-02-01 19:34:21 +08:00
FUNCTION_PASS("simplify-cfg", SimplifyCFGPass())
[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
FUNCTION_PASS("verify", VerifierPass())
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 18:19:28 +08:00
FUNCTION_PASS("verify<domtree>", DominatorTreeVerifierPass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 16:08:50 +08:00
#undef FUNCTION_PASS