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

225 lines
9.9 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
[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
MODULE_ANALYSIS("callgraph", CallGraphAnalysis())
[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
MODULE_ANALYSIS("lcg", LazyCallGraphAnalysis())
[PM] Port ModuleSummaryIndex analysis to new pass manager Summary: Port the ModuleSummaryAnalysisWrapperPass to the new pass manager. Use it in the ported BitcodeWriterPass (similar to how we use the legacy ModuleSummaryAnalysisWrapperPass in the legacy WriteBitcodePass). Also, pass the -module-summary opt flag through to the new pass manager pipeline and through to the bitcode writer pass, and add a test that uses it. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23439 llvm-svn: 278508
2016-08-12 21:53:02 +08:00
MODULE_ANALYSIS("module-summary", ModuleSummaryIndexAnalysis())
[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())
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 06:54:26 +08:00
MODULE_ANALYSIS("profile-summary", ProfileSummaryAnalysis())
[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())
Separate the Verifier into an analysis and a transformation pass and allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
2016-05-10 03:57:29 +08:00
MODULE_ANALYSIS("verify", VerifierAnalysis())
[PM/AA] Teach the AAManager how to handle module analyses in addition to function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
2016-03-11 17:15:11 +08:00
#ifndef MODULE_ALIAS_ANALYSIS
[CFLAA] Split into Anders+Steens analysis. StratifiedSets (as implemented) is very fast, but its accuracy is also limited. If we take a more aggressive andersens-like approach, we can be way more accurate, but we'll also end up being slower. So, we've decided to split CFLAA into CFLSteensAA and CFLAndersAA. Long-term, we want to end up in a place where CFLSteens is queried first; if it can provide an answer, great (since queries are basically map lookups). Otherwise, we'll fall back to CFLAnders, BasicAA, etc. This patch splits everything out so we can try to do something like that when we get a reasonable CFLAnders implementation. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21910 llvm-svn: 274589
2016-07-06 08:26:41 +08:00
#define MODULE_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
[PM/AA] Teach the AAManager how to handle module analyses in addition to function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
2016-03-11 17:15:11 +08:00
MODULE_ANALYSIS(NAME, CREATE_PASS)
#endif
MODULE_ALIAS_ANALYSIS("globals-aa", GlobalsAA())
#undef MODULE_ALIAS_ANALYSIS
[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] Port the always inliner to the new pass manager in a much more minimal and boring form than the old pass manager's version. This pass does the very minimal amount of work necessary to inline functions declared as always-inline. It doesn't support a wide array of things that the legacy pass manager did support, but is alse ... about 20 lines of code. So it has that going for it. Notably things this doesn't support: - Array alloca merging - To support the above, bottom-up inlining with careful history tracking and call graph updates - DCE of the functions that become dead after this inlining. - Inlining through call instructions with the always_inline attribute. Instead, it focuses on inlining functions with that attribute. The first I've omitted because I'm hoping to just turn it off for the primary pass manager. If that doesn't pan out, I can add it here but it will be reasonably expensive to do so. The second should really be handled by running global-dce after the inliner. I don't want to re-implement the non-trivial logic necessary to do comdat-correct DCE of functions. This means the -O0 pipeline will have to be at least 'always-inline,global-dce', but that seems reasonable to me. If others are seriously worried about this I'd like to hear about it and understand why. Again, this is all solveable by factoring that logic into a utility and calling it here, but I'd like to wait to do that until there is a clear reason why the existing pass-based factoring won't work. The final point is a serious one. I can fairly easily add support for this, but it seems both costly and a confusing construct for the use case of the always inliner running at -O0. This attribute can of course still impact the normal inliner easily (although I find that a questionable re-use of the same attribute). I've started a discussion to sort out what semantics we want here and based on that can figure out if it makes sense ta have this complexity at O0 or not. One other advantage of this design is that it should be quite a bit faster due to checking for whether the function is a viable candidate for inlining exactly once per function instead of doing it for each call site. Anyways, hopefully a reasonable starting point for this pass. Differential Revision: https://reviews.llvm.org/D23299 llvm-svn: 278896
2016-08-17 10:56:20 +08:00
MODULE_PASS("always-inline", AlwaysInlinerPass())
[PM] Port ConstantMerge to the new pass manager. llvm-svn: 268582
2016-05-05 08:51:09 +08:00
MODULE_PASS("constmerge", ConstantMergePass())
[PM] Port CrossDSOCFI to the new pass manager. llvm-svn: 274962
2016-07-09 11:25:35 +08:00
MODULE_PASS("cross-dso-cfi", CrossDSOCFIPass())
[PM] Port DeadArgumentElimination to the new PM The approach taken here follows r267631. deadarghaX0r should be easy to port when the time comes to add new-PM support to bugpoint. llvm-svn: 272507
2016-06-12 17:16:39 +08:00
MODULE_PASS("deadargelim", DeadArgumentEliminationPass())
[PM] Port EliminateAvailableExternally pass to the new pass manager. llvm-svn: 268599
2016-05-05 10:37:32 +08:00
MODULE_PASS("elim-avail-extern", EliminateAvailableExternallyPass())
[attrs] Split off the forced attributes utility into its own pass that is (by default) run much earlier than FuncitonAttrs proper. This allows forcing optnone or other widely impactful attributes. It is also a bit simpler as the force attribute behavior needs no specific iteration order. I've added the pass into the default module pass pipeline and LTO pass pipeline which mirrors where function attrs itself was being run. Differential Revision: http://reviews.llvm.org/D15668 llvm-svn: 256465
2015-12-27 16:13:45 +08:00
MODULE_PASS("forceattrs", ForceFunctionAttrsPass())
[PM] Port FunctionImport Pass to new PM Summary: Port FunctionImport Pass to new PM. Reviewers: mehdi_amini, davide Subscribers: davidxl, llvm-commits Differential Revision: https://reviews.llvm.org/D22475 llvm-svn: 275916
2016-07-19 05:22:24 +08:00
MODULE_PASS("function-import", FunctionImportPass())
[IPO/GlobalDCE] Port to the new pass manager. Differential Revision: http://reviews.llvm.org/D19782 llvm-svn: 268425
2016-05-04 03:39:15 +08:00
MODULE_PASS("globaldce", GlobalDCEPass())
PM: Port GlobalOpt to the new pass manager llvm-svn: 267499
2016-04-26 08:28:01 +08:00
MODULE_PASS("globalopt", GlobalOptPass())
[attrs] Extract the pure inference of function attributes into a standalone pass. There is no call graph or even interesting analysis for this part of function attributes -- it is literally inferring attributes based on the target library identification. As such, we can do it using a much simpler module pass that just walks the declarations. This can also happen much earlier in the pass pipeline which has benefits for any number of other passes. In the process, I've cleaned up one particular aspect of the logic which was necessary in order to separate the two passes cleanly. It now counts inferred attributes independently rather than just counting all the inferred attributes as one, and the counts are more clearly explained. The two test cases we had for this code path are both ... woefully inadequate and copies of each other. I've kept the superset test and updated it. We need more testing here, but I had to pick somewhere to stop fixing everything broken I saw here. Differential Revision: http://reviews.llvm.org/D15676 llvm-svn: 256466
2015-12-27 16:41:34 +08:00
MODULE_PASS("inferattrs", InferFunctionAttrsPass())
[PM] Port GCOVProfiler pass to the new pass manager llvm-svn: 271823
2016-06-05 13:12:23 +08:00
MODULE_PASS("insert-gcov-profiling", GCOVProfilerPass())
Port InstrProfiling pass to the new pass manager Differential Revision: http://reviews.llvm.org/D18126 llvm-svn: 266637
2016-04-19 01:47:38 +08:00
MODULE_PASS("instrprof", InstrProfiling())
Fix pass declaration order /NFC llvm-svn: 271824
2016-06-05 13:15:45 +08:00
MODULE_PASS("internalize", InternalizePass())
[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] Port Interprocedural SCCP to the new pass manager. llvm-svn: 268684
2016-05-06 05:05:36 +08:00
MODULE_PASS("ipsccp", IPSCCPPass())
[PM/IPO] Port LowerTypeTests to the new PassManager. There's a little bit of churn in this patch because the initialization mechanism is now shared between the old and the new PM. Other than that, it's just a pretty mechanical translation. llvm-svn: 275082
2016-07-12 02:10:06 +08:00
MODULE_PASS("lowertypetests", LowerTypeTestsPass())
Fix test after renaming -name-anon-functions pass to -name-anon-globals llvm-svn: 281752
2016-09-17 01:18:16 +08:00
MODULE_PASS("name-anon-globals", NameAnonGlobalPass())
[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] Port PartialInlining to the new PM Differential revision: http://reviews.llvm.org/D21699 llvm-svn: 273894
2016-06-28 00:50:18 +08:00
MODULE_PASS("partial-inliner", PartialInlinerPass())
[PM] Port indirect call promotion pass to new pass manager llvm-svn: 269660
2016-05-17 00:31:07 +08:00
MODULE_PASS("pgo-icall-prom", PGOIndirectCallPromotion())
[PM] port IR based PGO prof-gen pass to new pass manager llvm-svn: 268710
2016-05-06 13:49:19 +08:00
MODULE_PASS("pgo-instr-gen", PGOInstrumentationGen())
[PM]: port IR based profUse pass to new pass manager llvm-svn: 269129
2016-05-11 05:59:52 +08:00
MODULE_PASS("pgo-instr-use", PGOInstrumentationUse())
[PM] Port PreISelIntrinsicLowering to the new PM llvm-svn: 273713
2016-06-25 04:13:42 +08:00
MODULE_PASS("pre-isel-intrinsic-lowering", PreISelIntrinsicLoweringPass())
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 06:54:26 +08:00
MODULE_PASS("print-profile-summary", ProfileSummaryPrinterPass(dbgs()))
Revert r271728 as it breaks Windows build llvm-svn: 271738
2016-06-04 05:14:26 +08:00
MODULE_PASS("print-callgraph", CallGraphPrinterPass(dbgs()))
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 06:54:26 +08:00
MODULE_PASS("print", PrintModulePass(dbgs()))
[LCG] Spell the printing pass pipeline name for the lazy call graph 'lcg' instead of just 'cg'. This makes it consistent with the analysis name of 'lcg'. No functionality changed. llvm-svn: 263103
2016-03-10 19:24:06 +08:00
MODULE_PASS("print-lcg", LazyCallGraphPrinterPass(dbgs()))
Add a super basic LazyCallGraph DOT printer. Access it through -passes=print-lcg-dot Let me know any suggestions for changing the rendering; I'm not particularly attached to what is implemented here. llvm-svn: 273082
2016-06-18 17:17:32 +08:00
MODULE_PASS("print-lcg-dot", LazyCallGraphDOTPrinterPass(dbgs()))
[PM] Port SymbolRewriter to the new PM Differential Revision: https://reviews.llvm.org/D22703 llvm-svn: 276687
2016-07-26 04:52:00 +08:00
MODULE_PASS("rewrite-symbols", RewriteSymbolPass())
[PM] Port ReversePostOrderFunctionAttrs to the new PM Below are my super rough notes when porting. They can probably serve as a basic guide for porting other passes to the new PM. As I port more passes I'll expand and generalize this and make a proper docs/HowToPortToNewPassManager.rst document. There is also missing documentation for general concepts and API's in the new PM which will require some documentation. Once there is proper documentation in place we can put up a list of passes that have to be ported and game-ify/crowdsource the rest of the porting (at least of the middle end; the backend is still unclear). I will however be taking personal responsibility for ensuring that the LLD/ELF LTO pipeline is ported in a timely fashion. The remaining passes to be ported are (do something like `git grep "<the string in the bullet point below>"` to find the pass): General Scalar: [ ] Simplify the CFG [ ] Jump Threading [ ] MemCpy Optimization [ ] Promote Memory to Register [ ] MergedLoadStoreMotion [ ] Lazy Value Information Analysis General IPO: [ ] Dead Argument Elimination [ ] Deduce function attributes in RPO Loop stuff / vectorization stuff: [ ] Alignment from assumptions [ ] Canonicalize natural loops [ ] Delete dead loops [ ] Loop Access Analysis [ ] Loop Invariant Code Motion [ ] Loop Vectorization [ ] SLP Vectorizer [ ] Unroll loops Devirtualization / CFI: [ ] Cross-DSO CFI [ ] Whole program devirtualization [ ] Lower bitset metadata CGSCC passes: [ ] Function Integration/Inlining [ ] Remove unused exception handling info [ ] Promote 'by reference' arguments to scalars Please let me know if you are interested in working on any of the passes in the above list (e.g. reply to the post-commit thread for this patch). I'll probably be tackling "General Scalar" and "General IPO" first FWIW. Steps as I port "Deduce function attributes in RPO" --------------------------------------------------- (note: if you are doing any work based on these notes, please leave a note in the post-commit review thread for this commit with any improvements / suggestions / incompleteness you ran into!) Note: "Deduce function attributes in RPO" is a module pass. 1. Do preparatory refactoring. Do preparatory factoring. In this case all I had to do was to pull out a static helper (r272503). (TODO: give more advice here e.g. if pass holds state or something) 2. Rename the old pass class. llvm/lib/Transforms/IPO/FunctionAttrs.cpp Rename class ReversePostOrderFunctionAttrs -> ReversePostOrderFunctionAttrsLegacyPass in preparation for adding a class ReversePostOrderFunctionAttrs as the pass in the new PM. (edit: actually wait what? The new class name will be ReversePostOrderFunctionAttrsPass, so it doesn't conflict. So this step is sort of useless churn). llvm/include/llvm/InitializePasses.h llvm/lib/LTO/LTOCodeGenerator.cpp llvm/lib/Transforms/IPO/IPO.cpp llvm/lib/Transforms/IPO/FunctionAttrs.cpp Rename initializeReversePostOrderFunctionAttrsPass -> initializeReversePostOrderFunctionAttrsLegacyPassPass (note that the "PassPass" thing falls out of `s/ReversePostOrderFunctionAttrs/ReversePostOrderFunctionAttrsLegacyPass/`) Note that the INITIALIZE_PASS macro is what creates this identifier name, so renaming the class requires this renaming too. Note that createReversePostOrderFunctionAttrsPass does not need to be renamed since its name is not generated from the class name. 3. Add the new PM pass class. In the new PM all passes need to have their declaration in a header somewhere, so you will often need to add a header. In this case llvm/include/llvm/Transforms/IPO/FunctionAttrs.h is already there because PostOrderFunctionAttrsPass was already ported. The file-level comment from the .cpp file can be used as the file-level comment for the new header. You may want to tweak the wording slightly from "this file implements" to "this file provides" or similar. Add declaration for the new PM pass in this header: class ReversePostOrderFunctionAttrsPass : public PassInfoMixin<ReversePostOrderFunctionAttrsPass> { public: PreservedAnalyses run(Module &M, AnalysisManager<Module> &AM); }; Its name should end with `Pass` for consistency (note that this doesn't collide with the names of most old PM passes). E.g. call it `<name of the old PM pass>Pass`. Also, move the doxygen comment from the old PM pass to the declaration of this class in the header. Also, include the declaration for the new PM class `llvm/Transforms/IPO/FunctionAttrs.h` at the top of the file (in this case, it was already done when the other pass in this file was ported). Now define the `run` method for the new class. The main things here are: a) Use AM.getResult<...>(M) to get results instead of `getAnalysis<...>()` b) If the old PM pass would have returned "false" (i.e. `Changed == false`), then you should return PreservedAnalyses::all(); c) In the old PM getAnalysisUsage method, observe the calls `AU.addPreserved<...>();`. In the case `Changed == true`, for each preserved analysis you should do call `PA.preserve<...>()` on a PreservedAnalyses object and return it. E.g.: PreservedAnalyses PA; PA.preserve<CallGraphAnalysis>(); return PA; Note that calls to skipModule/skipFunction are not supported in the new PM currently, so optnone and optimization bisect support do not work. You can just drop those calls for now. 4. Add the pass to the new PM pass registry to make it available in opt. In llvm/lib/Passes/PassBuilder.cpp add a #include for your header. `#include "llvm/Transforms/IPO/FunctionAttrs.h"` In this case there is already an include (from when PostOrderFunctionAttrsPass was ported). Add your pass to llvm/lib/Passes/PassRegistry.def In this case, I added `MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())` The string is from the `INITIALIZE_PASS*` macros used in the old pass manager. Then choose a test that uses the pass and use the new PM `-passes=...` to run it. E.g. in this case there is a test that does: ; RUN: opt < %s -basicaa -functionattrs -rpo-functionattrs -S | FileCheck %s I have added the line: ; RUN: opt < %s -aa-pipeline=basic-aa -passes='require<targetlibinfo>,cgscc(function-attrs),rpo-functionattrs' -S | FileCheck %s The `-aa-pipeline=basic-aa` and `require<targetlibinfo>,cgscc(function-attrs)` are what is needed to run functionattrs in the new PM (note that in the new PM "functionattrs" becomes "function-attrs" for some reason). This is just pulled from `readattrs.ll` which contains the change from when functionattrs was ported to the new PM. Adding rpo-functionattrs causes the pass that was just ported to run. llvm-svn: 272505
2016-06-12 15:48:51 +08:00
MODULE_PASS("rpo-functionattrs", ReversePostOrderFunctionAttrsPass())
[PM] Port the Sample FDO to new PM (part-2) llvm-svn: 271072
2016-05-28 07:20:16 +08:00
MODULE_PASS("sample-profile", SampleProfileLoaderPass())
[PM] Port StripDeadPrototypes to the new pass manager This is a really straightforward port. Also adds a test for the pass, since it only seemed to be tested tangentially before. llvm-svn: 251726
2015-10-31 07:28:12 +08:00
MODULE_PASS("strip-dead-prototypes", StripDeadPrototypesPass())
[PM] Port WholeProgramDevirt to the new pass manager. llvm-svn: 272721
2016-06-15 05:44:19 +08:00
MODULE_PASS("wholeprogramdevirt", WholeProgramDevirtPass())
[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] Port the PostOrderFunctionAttrs pass to the new pass manager and convert one test to use this. This is a particularly significant milestone because it required a working per-function AA framework which can be queried over each function from within a CGSCC transform pass (and additionally a module analysis to be accessible). This is essentially *the* point of the entire pass manager rewrite. A CGSCC transform is able to query for multiple different function's analysis results. It works. The whole thing appears to actually work and accomplish the original goal. While we were able to hack function attrs and basic-aa to "work" in the old pass manager, this port doesn't use any of that, it directly leverages the new fundamental functionality. For this to work, the CGSCC framework also has to support SCC-based behavior analysis, etc. The only part of the CGSCC pass infrastructure not sorted out at this point are the updates in the face of inlining and running function passes that mutate the call graph. The changes are pretty boring and boiler-plate. Most of the work was factored into more focused preperatory patches. But this is what wires it all together. llvm-svn: 261203
2016-02-18 19:03:11 +08:00
CGSCC_PASS("function-attrs", PostOrderFunctionAttrsPass())
[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/AA] Actually wire the AAManager I built for the new pass manager into the new pass manager and fix the latent bugs there. This lets everything live together nicely, but it isn't really useful yet. I never finished wiring the AA layer up for the new pass manager, and so subsequent patches will change this to do that wiring and get AA stuff more fully integrated into the new pass manager. Turns out this is necessary even to get functionattrs ported over. =] llvm-svn: 260836
2016-02-14 07:32:00 +08:00
FUNCTION_ANALYSIS("aa", AAManager())
[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 Branch Frequency Analaysis pass to new PM llvm-svn: 268687
2016-05-06 05:13:27 +08:00
FUNCTION_ANALYSIS("block-freq", BlockFrequencyAnalysis())
[PM] Port Branch Probability Analysis pass to the new pass manager. Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
2016-05-05 10:59:57 +08:00
FUNCTION_ANALYSIS("branch-prob", BranchProbabilityAnalysis())
[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())
Introduce analysis pass to compute PostDominators in the new pass manager. NFC Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261902
2016-02-26 01:54:07 +08:00
FUNCTION_ANALYSIS("postdomtree", PostDominatorTreeAnalysis())
Port DemandedBits to the new pass manager. Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
2016-04-19 07:55:01 +08:00
FUNCTION_ANALYSIS("demanded-bits", DemandedBitsAnalysis())
Introduce DominanceFrontierAnalysis to the new PassManager to compute DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261903
2016-02-26 01:54:15 +08:00
FUNCTION_ANALYSIS("domfrontier", DominanceFrontierAnalysis())
[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] Port LVI to the new PM. This is a bit gnarly since LVI is maintaining its own cache. I think this port could be somewhat cleaner, but I'd rather not spend too much time on it while we still have the old pass hanging around and limiting how much we can clean things up. Once the old pass is gone it will be easier (less time spent) to clean it up anyway. This is the last dependency needed for porting JumpThreading which I'll do in a follow-up commit (there's no printer pass for LVI or anything to test it, so porting a pass that depends on it seems best). I've been mostly following: r269370 / D18834 which ported Dependence Analysis r268601 / D19839 which ported BPI llvm-svn: 272593
2016-06-14 06:01:25 +08:00
FUNCTION_ANALYSIS("lazy-value-info", LazyValueAnalysis())
[PM] Port of the DepndenceAnalysis to the new PM. Ported DA to the new PM by splitting the former DependenceAnalysis Pass into a DependenceInfo result type and DependenceAnalysisWrapperPass type and adding a new PM-style DependenceAnalysis analysis pass returning the DependenceInfo. Patch by Philip Pfaffe, most of the review by Justin. Differential Revision: http://reviews.llvm.org/D18834 llvm-svn: 269370
2016-05-13 06:19:39 +08:00
FUNCTION_ANALYSIS("da", DependenceAnalysis())
[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
FUNCTION_ANALYSIS("memdep", MemoryDependenceAnalysis())
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-02 05:30:40 +08:00
FUNCTION_ANALYSIS("memoryssa", MemorySSAAnalysis())
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-26 01:54:25 +08:00
FUNCTION_ANALYSIS("regions", RegionInfoAnalysis())
[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())
[OptRemarkEmitter] Port to new PM Summary: The main goal is to able to start using the new OptRemarkEmitter analysis from the LoopVectorizer. Since the vectorizer was recently converted to the new PM, it makes sense to convert this analysis as well. This pass is currently tested through the LoopDistribution pass, so I am also porting LoopDistribution to get coverage for this analysis with the new PM. Reviewers: davidxl, silvas Subscribers: llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22436 llvm-svn: 275810
2016-07-19 00:29:21 +08:00
FUNCTION_ANALYSIS("opt-remark-emit", OptimizationRemarkEmitterAnalysis())
[PM] Port ScalarEvolution to the new pass manager. This change makes ScalarEvolution a stand-alone object and just produces one from a pass as needed. Making this work well requires making the object movable, using references instead of overwritten pointers in a number of places, and other refactorings. I've also wired it up to the new pass manager and added a RUN line to a test to exercise it under the new pass manager. This includes basic printing support much like with other analyses. But there is a big and somewhat scary change here. Prior to this patch ScalarEvolution was never *actually* invalidated!!! Re-running the pass just re-wired up the various other analyses and didn't remove any of the existing entries in the SCEV caches or clear out anything at all. This might seem OK as everything in SCEV that can uses ValueHandles to track updates to the values that serve as SCEV keys. However, this still means that as we ran SCEV over each function in the module, we kept accumulating more and more SCEVs into the cache. At the end, we would have a SCEV cache with every value that we ever needed a SCEV for in the entire module!!! Yowzers. The releaseMemory routine would dump all of this, but that isn't realy called during normal runs of the pipeline as far as I can see. To make matters worse, there *is* actually a key that we don't update with value handles -- there is a map keyed off of Loop*s. Because LoopInfo *does* release its memory from run to run, it is entirely possible to run SCEV over one function, then over another function, and then lookup a Loop* from the second function but find an entry inserted for the first function! Ouch. To make matters still worse, there are plenty of updates that *don't* trip a value handle. It seems incredibly unlikely that today GVN or another pass that invalidates SCEV can update values in *just* such a way that a subsequent run of SCEV will incorrectly find lookups in a cache, but it is theoretically possible and would be a nightmare to debug. With this refactoring, I've fixed all this by actually destroying and recreating the ScalarEvolution object from run to run. Technically, this could increase the amount of malloc traffic we see, but then again it is also technically correct. ;] I don't actually think we're suffering from tons of malloc traffic from SCEV because if we were, the fact that we never clear the memory would seem more likely to have come up as an actual problem before now. So, I've made the simple fix here. If in fact there are serious issues with too much allocation and deallocation, I can work on a clever fix that preserves the allocations (while clearing the data) between each run, but I'd prefer to do that kind of optimization with a test case / benchmark that shows why we need such cleverness (and that can test that we actually make it faster). It's possible that this will make some things faster by making the SCEV caches have higher locality (due to being significantly smaller) so until there is a clear benchmark, I think the simple change is best. Differential Revision: http://reviews.llvm.org/D12063 llvm-svn: 245193
2015-08-17 10:08:17 +08:00
FUNCTION_ANALYSIS("scalar-evolution", ScalarEvolutionAnalysis())
[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())
Separate the Verifier into an analysis and a transformation pass and allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 This reapplies r268937 without modifications. llvm-svn: 268966
2016-05-10 03:57:29 +08:00
FUNCTION_ANALYSIS("verify", VerifierAnalysis())
[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
#ifndef FUNCTION_ALIAS_ANALYSIS
#define FUNCTION_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
FUNCTION_ANALYSIS(NAME, CREATE_PASS)
#endif
FUNCTION_ALIAS_ANALYSIS("basic-aa", BasicAA())
[CFLAA] Split into Anders+Steens analysis. StratifiedSets (as implemented) is very fast, but its accuracy is also limited. If we take a more aggressive andersens-like approach, we can be way more accurate, but we'll also end up being slower. So, we've decided to split CFLAA into CFLSteensAA and CFLAndersAA. Long-term, we want to end up in a place where CFLSteens is queried first; if it can provide an answer, great (since queries are basically map lookups). Otherwise, we'll fall back to CFLAnders, BasicAA, etc. This patch splits everything out so we can try to do something like that when we get a reasonable CFLAnders implementation. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21910 llvm-svn: 274589
2016-07-06 08:26:41 +08:00
FUNCTION_ALIAS_ANALYSIS("cfl-anders-aa", CFLAndersAA())
FUNCTION_ALIAS_ANALYSIS("cfl-steens-aa", CFLSteensAA())
[PM/AA] Wire up SCEVAA to the new pass manager's registry and test it. llvm-svn: 261409
2016-02-20 12:01:45 +08:00
FUNCTION_ALIAS_ANALYSIS("scev-aa", SCEVAA())
[PM/AA] Wire up the scoped-no-alias AA to the new pass manager's registry and test it. llvm-svn: 261410
2016-02-20 12:03:06 +08:00
FUNCTION_ALIAS_ANALYSIS("scoped-noalias-aa", ScopedNoAliasAA())
[PM/AA] Wire up TBAA to the new pass manager's registry and test it. llvm-svn: 261411
2016-02-20 12:04:52 +08:00
FUNCTION_ALIAS_ANALYSIS("type-based-aa", TypeBasedAA())
[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
#undef FUNCTION_ALIAS_ANALYSIS
[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/AA] Port alias analysis evaluator to the new pass manager, and use it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
2016-02-20 11:46:03 +08:00
FUNCTION_PASS("aa-eval", AAEvaluator())
[PM] Port ADCE to the new pass manager llvm-svn: 251725
2015-10-31 07:13:18 +08:00
FUNCTION_PASS("adce", ADCEPass())
[PM] Port Add discriminator pass to new PM llvm-svn: 272847
2016-06-16 05:51:30 +08:00
FUNCTION_PASS("add-discriminators", AddDiscriminatorsPass())
[PM] Port AlignmentFromAssumptions to the new PM. This uses the "runImpl" pattern to share code between the old and new PM. llvm-svn: 272757
2016-06-15 14:18:01 +08:00
FUNCTION_PASS("alignment-from-assumptions", AlignmentFromAssumptionsPass())
[PM] Port BDCE to the new pass manager. llvm-svn: 270647
2016-05-25 09:57:04 +08:00
FUNCTION_PASS("bdce", BDCEPass())
[PM] Port BreakCriticalEdges to the new PM. Differential Revision: https://reviews.llvm.org/D22688 llvm-svn: 276449
2016-07-23 02:04:25 +08:00
FUNCTION_PASS("break-crit-edges", BreakCriticalEdgesPass())
[PM] Port ConstantHoisting to the new Pass Manager Differential Revision: http://reviews.llvm.org/D21945 llvm-svn: 274411
2016-07-02 08:16:47 +08:00
FUNCTION_PASS("consthoist", ConstantHoistingPass())
[PM] Port CorrelatedValuePropagation llvm-svn: 274705
2016-07-07 07:26:29 +08:00
FUNCTION_PASS("correlated-propagation", CorrelatedValuePropagationPass())
PM: Port DCE to the new pass manager Also add a very basic test, since apparently there aren't any tests for DCE whatsoever to add the new pass version to. llvm-svn: 267196
2016-04-23 03:40:41 +08:00
FUNCTION_PASS("dce", DCEPass())
[PM] Port DSE to the new pass manager Patch by JakeVanAdrighem. Thanks! llvm-svn: 269847
2016-05-18 05:38:13 +08:00
FUNCTION_PASS("dse", DSEPass())
[PM] Port CFGViewer and CFGPrinter to the new Pass Manager Differential Revision: https://reviews.llvm.org/D24592 llvm-svn: 281640
2016-09-16 02:35:27 +08:00
FUNCTION_PASS("dot-cfg", CFGPrinterPass())
FUNCTION_PASS("dot-cfg-only", CFGOnlyPrinterPass())
[EarlyCSE] Optionally use MemorySSA. NFC. Summary: Use MemorySSA, if requested, to do less conservative memory dependency checking. This change doesn't enable the MemorySSA enhanced EarlyCSE in the default pipelines, so should be NFC. Reviewers: dberlin, sanjoy, reames, majnemer Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19821 llvm-svn: 280279
2016-09-01 03:24:10 +08:00
FUNCTION_PASS("early-cse", EarlyCSEPass(/*UseMemorySSA=*/false))
FUNCTION_PASS("early-cse-memssa", EarlyCSEPass(/*UseMemorySSA=*/true))
code hoisting pass based on GVN This pass hoists duplicated computations in the program. The primary goal of gvn-hoist is to reduce the size of functions before inline heuristics to reduce the total cost of function inlining. Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki. Important algorithmic contributions by Daniel Berlin under the form of reviews. Differential Revision: http://reviews.llvm.org/D19338 llvm-svn: 275561
2016-07-15 21:45:20 +08:00
FUNCTION_PASS("gvn-hoist", GVNHoistPass())
[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] Port InstSimplify to the new pass manager. llvm-svn: 274796
2016-07-08 05:14:36 +08:00
FUNCTION_PASS("instsimplify", InstSimplifierPass())
[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] Port float2int to the new pass manager Differential Revision: http://reviews.llvm.org/D21704 llvm-svn: 273747
2016-06-25 07:32:02 +08:00
FUNCTION_PASS("float2int", Float2IntPass())
[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 LowerAtomic to the new pass manager. llvm-svn: 269511
2016-05-14 06:52:35 +08:00
FUNCTION_PASS("loweratomic", LowerAtomicPass())
[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] Port LowerGuardIntrinsic to the new PM. llvm-svn: 277057
2016-07-29 06:08:41 +08:00
FUNCTION_PASS("lower-guard-intrinsic", LowerGuardIntrinsicPass())
New pass: guard widening Summary: Implement guard widening in LLVM. Description from GuardWidening.cpp: The semantics of the `@llvm.experimental.guard` intrinsic lets LLVM transform it so that it fails more often that it did before the transform. This optimization is called "widening" and can be used hoist and common runtime checks in situations like these: ``` %cmp0 = 7 u< Length call @llvm.experimental.guard(i1 %cmp0) [ "deopt"(...) ] call @unknown_side_effects() %cmp1 = 9 u< Length call @llvm.experimental.guard(i1 %cmp1) [ "deopt"(...) ] ... ``` to ``` %cmp0 = 9 u< Length call @llvm.experimental.guard(i1 %cmp0) [ "deopt"(...) ] call @unknown_side_effects() ... ``` If `%cmp0` is false, `@llvm.experimental.guard` will "deoptimize" back to a generic implementation of the same function, which will have the correct semantics from that point onward. It is always _legal_ to deoptimize (so replacing `%cmp0` with false is "correct"), though it may not always be profitable to do so. NB! This pass is a work in progress. It hasn't been tuned to be "production ready" yet. It is known to have quadriatic running time and will not scale to large numbers of guards Reviewers: reames, atrick, bogner, apilipenko, nlewycky Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20143 llvm-svn: 269997
2016-05-19 06:55:34 +08:00
FUNCTION_PASS("guard-widening", GuardWideningPass())
[PM] Port GVN to the new pass manager, wire it up, and teach a couple of tests to run GVN in both modes. This is mostly the boring refactoring just like SROA and other complex transformation passes. There is some trickiness in that GVN's ValueNumber class requires hand holding to get to compile cleanly. I'm open to suggestions about a better pattern there, but I tried several before settling on this. I was trying to balance my desire to sink as much implementation detail into the source file as possible without introducing overly many layers of abstraction. Much like with SROA, the design of this system is made somewhat more cumbersome by the need to support both pass managers without duplicating the significant state and logic of the pass. The same compromise is struck here. I've also left a FIXME in a doxygen comment as the GVN pass seems to have pretty woeful documentation within it. I'd like to submit this with the FIXME and let those more deeply familiar backfill the information here now that we have a nice place in an interface to put that kind of documentaiton. Differential Revision: http://reviews.llvm.org/D18019 llvm-svn: 263208
2016-03-11 16:50:55 +08:00
FUNCTION_PASS("gvn", GVN())
[PM] Port LoopSimplify to the new pass manager. While here move simplifyLoop() function to the new header, as suggested by Chandler in the review. Differential Revision: http://reviews.llvm.org/D21404 llvm-svn: 274959
2016-07-09 11:03:01 +08:00
FUNCTION_PASS("loop-simplify", LoopSimplifyPass())
[PM] Port LowerInvoke to the new pass manager llvm-svn: 278531
2016-08-13 01:28:27 +08:00
FUNCTION_PASS("lowerinvoke", LowerInvokePass())
[PM] Port Mem2Reg to the new pass manager. llvm-svn: 272630
2016-06-14 11:22:22 +08:00
FUNCTION_PASS("mem2reg", PromotePass())
[PM] Port MemCpyOpt to the new PM. The need for all these Lookup* functions is just because of calls to getAnalysis inside methods (i.e. not at the top level) of the runOnFunction method. They should be straightforward to clean up when the old PM is gone. llvm-svn: 272615
2016-06-14 10:44:55 +08:00
FUNCTION_PASS("memcpyopt", MemCpyOptPass())
[PM] Port MergedLoadStoreMotion to the new pass manager, take two. This is indeed a much cleaner approach (thanks to Daniel Berlin for pointing out), and also David/Sean for review. Differential Revision: http://reviews.llvm.org/D21454 llvm-svn: 273032
2016-06-18 03:10:09 +08:00
FUNCTION_PASS("mldst-motion", MergedLoadStoreMotionPass())
[PM] Port NaryReassociate to the new PM Differential Revision: https://reviews.llvm.org/D22648 llvm-svn: 276349
2016-07-22 06:28:52 +08:00
FUNCTION_PASS("nary-reassociate", NaryReassociatePass())
Bring back "[PM] Port JumpThreading to the new PM" with a fix This reverts commit r272603 and adds a fix. Big thanks to Davide for pointing me at r216244 which gives some insight into how to fix this VS2013 issue. VS2013 can't synthesize a move constructor. So the fix here is to add one explicitly to the JumpThreadingPass class. llvm-svn: 272607
2016-06-14 08:51:09 +08:00
FUNCTION_PASS("jump-threading", JumpThreadingPass())
[PM] Port PartiallyInlineLibCalls to the new pass manager. llvm-svn: 270798
2016-05-26 07:38:53 +08:00
FUNCTION_PASS("partially-inline-libcalls", PartiallyInlineLibCallsPass())
[PM] Port LCSSA to the new PM. Differential Revision: http://reviews.llvm.org/D21090 llvm-svn: 272294
2016-06-10 03:44:46 +08:00
FUNCTION_PASS("lcssa", LCSSAPass())
[PM] Port LoopDataPrefetch to new pass manager Summary: Refactor the existing support into a LoopDataPrefetch implementation class and a LoopDataPrefetchLegacyPass class that invokes it. Add a new LoopDataPrefetchPass for the new pass manager that utilizes the LoopDataPrefetch implementation class. Reviewers: mehdi_amini Subscribers: sanjoy, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D23483 llvm-svn: 278591
2016-08-13 12:11:27 +08:00
FUNCTION_PASS("loop-data-prefetch", LoopDataPrefetchPass())
[LoopDist] Port to new PM Summary: The direct motivation for the port is to ensure that the OptRemarkEmitter tests work with the new PM. This remains a function pass because we not only create multiple loops but could also version the original loop. In the test I need to invoke opt with -passes='require<aa>,loop-distribute'. LoopDistribute does not directly depend on AA however LAA does. LAA uses getCachedResult so I *think* we need manually pull in 'aa'. Reviewers: davidxl, silvas Subscribers: sanjoy, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22437 llvm-svn: 275811
2016-07-19 00:29:27 +08:00
FUNCTION_PASS("loop-distribute", LoopDistributePass())
[PM] Port LoopVectorize to the new PM. llvm-svn: 275000
2016-07-10 06:56:50 +08:00
FUNCTION_PASS("loop-vectorize", LoopVectorizePass())
[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 Branch Frequency Analaysis pass to new PM llvm-svn: 268687
2016-05-06 05:13:27 +08:00
FUNCTION_PASS("print<block-freq>", BlockFrequencyPrinterPass(dbgs()))
[PM] Port Branch Probability Analysis pass to the new pass manager. Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
2016-05-05 10:59:57 +08:00
FUNCTION_PASS("print<branch-prob>", BranchProbabilityPrinterPass(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()))
Introduce analysis pass to compute PostDominators in the new pass manager. NFC Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261902
2016-02-26 01:54:07 +08:00
FUNCTION_PASS("print<postdomtree>", PostDominatorTreePrinterPass(dbgs()))
Port DemandedBits to the new pass manager. Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
2016-04-19 07:55:01 +08:00
FUNCTION_PASS("print<demanded-bits>", DemandedBitsPrinterPass(dbgs()))
Introduce DominanceFrontierAnalysis to the new PassManager to compute DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261903
2016-02-26 01:54:15 +08:00
FUNCTION_PASS("print<domfrontier>", DominanceFrontierPrinterPass(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()))
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-02 05:30:40 +08:00
FUNCTION_PASS("print<memoryssa>", MemorySSAPrinterPass(dbgs()))
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-26 01:54:25 +08:00
FUNCTION_PASS("print<regions>", RegionInfoPrinterPass(dbgs()))
[PM] Port ScalarEvolution to the new pass manager. This change makes ScalarEvolution a stand-alone object and just produces one from a pass as needed. Making this work well requires making the object movable, using references instead of overwritten pointers in a number of places, and other refactorings. I've also wired it up to the new pass manager and added a RUN line to a test to exercise it under the new pass manager. This includes basic printing support much like with other analyses. But there is a big and somewhat scary change here. Prior to this patch ScalarEvolution was never *actually* invalidated!!! Re-running the pass just re-wired up the various other analyses and didn't remove any of the existing entries in the SCEV caches or clear out anything at all. This might seem OK as everything in SCEV that can uses ValueHandles to track updates to the values that serve as SCEV keys. However, this still means that as we ran SCEV over each function in the module, we kept accumulating more and more SCEVs into the cache. At the end, we would have a SCEV cache with every value that we ever needed a SCEV for in the entire module!!! Yowzers. The releaseMemory routine would dump all of this, but that isn't realy called during normal runs of the pipeline as far as I can see. To make matters worse, there *is* actually a key that we don't update with value handles -- there is a map keyed off of Loop*s. Because LoopInfo *does* release its memory from run to run, it is entirely possible to run SCEV over one function, then over another function, and then lookup a Loop* from the second function but find an entry inserted for the first function! Ouch. To make matters still worse, there are plenty of updates that *don't* trip a value handle. It seems incredibly unlikely that today GVN or another pass that invalidates SCEV can update values in *just* such a way that a subsequent run of SCEV will incorrectly find lookups in a cache, but it is theoretically possible and would be a nightmare to debug. With this refactoring, I've fixed all this by actually destroying and recreating the ScalarEvolution object from run to run. Technically, this could increase the amount of malloc traffic we see, but then again it is also technically correct. ;] I don't actually think we're suffering from tons of malloc traffic from SCEV because if we were, the fact that we never clear the memory would seem more likely to have come up as an actual problem before now. So, I've made the simple fix here. If in fact there are serious issues with too much allocation and deallocation, I can work on a clever fix that preserves the allocations (while clearing the data) between each run, but I'd prefer to do that kind of optimization with a test case / benchmark that shows why we need such cleverness (and that can test that we actually make it faster). It's possible that this will make some things faster by making the SCEV caches have higher locality (due to being significantly smaller) so until there is a clear benchmark, I think the simple change is best. Differential Revision: http://reviews.llvm.org/D12063 llvm-svn: 245193
2015-08-17 10:08:17 +08:00
FUNCTION_PASS("print<scalar-evolution>", ScalarEvolutionPrinterPass(dbgs()))
PM: Port Reassociate to the new pass manager llvm-svn: 267631
2016-04-27 07:39:29 +08:00
FUNCTION_PASS("reassociate", ReassociatePass())
[PM] Port per-function SCCP to the new pass manager. llvm-svn: 269937
2016-05-18 23:18:25 +08:00
FUNCTION_PASS("sccp", SCCPPass())
[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: Port SinkingPass to the new pass manager llvm-svn: 267199
2016-04-23 03:54:10 +08:00
FUNCTION_PASS("sink", SinkingPass())
[PM] Port SLPVectorizer to the new PM This uses the "runImpl" approach to share code with the old PM. Porting to the new PM meant abandoning the anonymous namespace enclosing most of SLPVectorizer.cpp which is a bit of a bummer (but not a big deal compared to having to pull the pass class into a header which the new PM requires since it calls the constructor directly). llvm-svn: 272766
2016-06-15 16:43:40 +08:00
FUNCTION_PASS("slp-vectorizer", SLPVectorizerPass())
[PM] Port SpeculativeExecution to the new PM Differential Revision: https://reviews.llvm.org/D23033 llvm-svn: 277393
2016-08-02 05:48:33 +08:00
FUNCTION_PASS("speculative-execution", SpeculativeExecutionPass())
[PM] Port SROA to the new pass manager. In some ways this is a very boring port to the new pass manager as there are no interesting analyses or dependencies or other oddities. However, this does introduce the first good example of a transformation pass with non-trivial state porting to the new pass manager. I've tried to carve out patterns here to replicate elsewhere, and would appreciate comments on whether folks like these patterns: - A common need in the new pass manager is to effectively lift the pass class and some of its state into a public header file. Prior to this, LLVM used anonymous namespaces to provide "module private" types and utilities, but that doesn't scale to cases where a public header file is needed and the new pass manager will exacerbate that. The pattern I've adopted here is to use the namespace-cased-name of the core pass (what would be a module if we had them) as a module-private namespace. Then utility and other code can be declared and defined in this namespace. At some point in the future, we could even have (conditionally compiled) code that used modules features when available to do the same basic thing. - I've split the actual pass run method in two in order to expose a private method usable by the old pass manager to wrap the new class with a minimum of duplicated code. I actually looked at a bunch of ways to automate or generate these, but they are all quite terrible IMO. The fundamental need is to extract the set of analyses which need to cross this interface boundary, and that will end up being too unpredictable to effectively encapsulate IMO. This is also a relatively small amount of boiler plate that will live a relatively short time, so I'm not too worried about the fact that it is boiler plate. The rest of the patch is totally boring but results in a massive diff (sorry). It just moves code around and removes or adds qualifiers to reflect the new name and nesting structure. Differential Revision: http://reviews.llvm.org/D12773 llvm-svn: 247501
2015-09-12 17:09:14 +08:00
FUNCTION_PASS("sroa", SROA())
[PM] Port TailCallElim llvm-svn: 274708
2016-07-07 07:48:41 +08:00
FUNCTION_PASS("tailcallelim", TailCallElimPass())
[PM] Port UnreachableBlockElim to the new Pass Manager Differential Revision: http://reviews.llvm.org/D22124 llvm-svn: 274824
2016-07-08 11:32:49 +08:00
FUNCTION_PASS("unreachableblockelim", UnreachableBlockElimPass())
[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] Port LoopUnroll. We just set PreserveLCSSA to always true since we don't have an analogous method `mustPreserveAnalysisID(LCSSA)`. Also port LoopInfo verifier pass to test LoopUnrollPass. llvm-svn: 276063
2016-07-20 07:54:23 +08:00
FUNCTION_PASS("verify<loops>", LoopVerifierPass())
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-02 05:30:40 +08:00
FUNCTION_PASS("verify<memoryssa>", MemorySSAVerifierPass())
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-26 01:54:25 +08:00
FUNCTION_PASS("verify<regions>", RegionInfoVerifierPass())
[PM] Port CFGViewer and CFGPrinter to the new Pass Manager Differential Revision: https://reviews.llvm.org/D24592 llvm-svn: 281640
2016-09-16 02:35:27 +08:00
FUNCTION_PASS("view-cfg", CFGViewerPass())
FUNCTION_PASS("view-cfg-only", CFGOnlyViewerPass())
[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
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 15:23:08 +08:00
#ifndef LOOP_ANALYSIS
#define LOOP_ANALYSIS(NAME, CREATE_PASS)
#endif
LOOP_ANALYSIS("no-op-loop", NoOpLoopAnalysis())
[PM] name the new PM LAA class LoopAccessAnalysis (LAA) /NFC llvm-svn: 274934
2016-07-09 05:21:44 +08:00
LOOP_ANALYSIS("access-info", LoopAccessAnalysis())
[PM] Convert IVUsers analysis to new pass manager. Summary: Convert IVUsers analysis to new pass manager. Reviewers: davidxl, silvas Subscribers: junbuml, sanjoy, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22434 llvm-svn: 275698
2016-07-17 06:51:33 +08:00
LOOP_ANALYSIS("ivusers", IVUsersAnalysis())
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 15:23:08 +08:00
#undef LOOP_ANALYSIS
#ifndef LOOP_PASS
#define LOOP_PASS(NAME, CREATE_PASS)
#endif
LOOP_PASS("invalidate<all>", InvalidateAllAnalysesPass())
Add missing files for r275222 New pass manager for LICM. Summary: Port LICM to the new pass manager. Reviewers: davidxl, silvas Subscribers: krasin, vitalybuka, silvas, davide, sanjoy, llvm-commits, mehdi_amini Differential Revision: http://reviews.llvm.org/D21772 llvm-svn: 275224
2016-07-13 06:42:24 +08:00
LOOP_PASS("licm", LICMPass())
[PM] Port LoopIdiomRecognize Pass to new PM Summary: Port LoopIdiomRecognize Pass to new PM Reviewers: davidxl Subscribers: davide, sanjoy, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D22250 llvm-svn: 275202
2016-07-13 02:45:51 +08:00
LOOP_PASS("loop-idiom", LoopIdiomRecognizePass())
[PM] Convert LoopInstSimplify Pass to new PM Summary: Convert LoopInstSimplify to new PM. Unfortunately there is no exisiting unittest for this pass. Reviewers: davidxl, silvas Subscribers: silvas, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22280 llvm-svn: 275576
2016-07-16 00:42:11 +08:00
LOOP_PASS("loop-instsimplify", LoopInstSimplifyPass())
PM: Port LoopRotation to the new loop pass manager llvm-svn: 268452
2016-05-04 06:02:31 +08:00
LOOP_PASS("rotate", LoopRotatePass())
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 15:23:08 +08:00
LOOP_PASS("no-op-loop", NoOpLoopPass())
LOOP_PASS("print", PrintLoopPass(dbgs()))
[PM] Port Dead Loop Deletion Pass to the new PM Summary: Port Dead Loop Deletion Pass to the new pass manager. Reviewers: silvas, davide Subscribers: llvm-commits, sanjoy, mcrosier Differential Revision: https://reviews.llvm.org/D21483 llvm-svn: 275453
2016-07-15 02:28:29 +08:00
LOOP_PASS("loop-deletion", LoopDeletionPass())
PM: Port LoopSimplifyCFG to the new pass manager llvm-svn: 268446
2016-05-04 05:47:32 +08:00
LOOP_PASS("simplify-cfg", LoopSimplifyCFGPass())
[PM] Convert Loop Strength Reduce pass to new PM Summary: Convert Loop String Reduce pass to new PM Reviewers: davidxl, silvas Subscribers: junbuml, sanjoy, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D22468 llvm-svn: 275919
2016-07-19 05:41:50 +08:00
LOOP_PASS("strength-reduce", LoopStrengthReducePass())
[PM] Port IndVarSimplify to the new pass manager Summary: There are some rough corners, since the new pass manager doesn't have (as far as I can tell) LoopSimplify and LCSSA, so I've updated the tests to run them separately in the old pass manager in the lit tests. We also don't have an equivalent for AU.setPreservesCFG() in the new pass manager, so I've left a FIXME. Reviewers: bogner, chandlerc, davide Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20783 llvm-svn: 271846
2016-06-06 02:01:19 +08:00
LOOP_PASS("indvars", IndVarSimplifyPass())
[PM] Port LoopUnroll. We just set PreserveLCSSA to always true since we don't have an analogous method `mustPreserveAnalysisID(LCSSA)`. Also port LoopInfo verifier pass to test LoopUnrollPass. llvm-svn: 276063
2016-07-20 07:54:23 +08:00
LOOP_PASS("unroll", LoopUnrollPass())
[PM] Port LoopAccessInfo analysis to new PM It is implemented as a LoopAnalysis pass as discussed and agreed upon. llvm-svn: 274452
2016-07-03 05:18:40 +08:00
LOOP_PASS("print-access-info", LoopAccessInfoPrinterPass(dbgs()))
[PM] Convert IVUsers analysis to new pass manager. Summary: Convert IVUsers analysis to new pass manager. Reviewers: davidxl, silvas Subscribers: junbuml, sanjoy, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22434 llvm-svn: 275698
2016-07-17 06:51:33 +08:00
LOOP_PASS("print<ivusers>", IVUsersPrinterPass(dbgs()))
PM: Implement a basic loop pass manager This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
2016-02-25 15:23:08 +08:00
#undef LOOP_PASS