summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Passes
Commit message (Collapse)AuthorAgeFilesLines
...
* [PM] Revert r279227 and r279228 until I can find someone to help meChandler Carruth2016-08-191-9/+6
| | | | | | | | solve completely opaque MSVC build errors. It complains about lots of stuff with this change without givin nearly enough information to even try to fix. llvm-svn: 279231
* [PM] Make the the new pass manager support fully generic extra argumentsChandler Carruth2016-08-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to run methods, both for transform passes and analysis passes. This also allows the analysis manager to use a different set of extra arguments from the pass manager where useful. Consider passes over analysis produced units of IR like SCCs of the call graph or loops. Passes of this nature will often want to refer to the analysis result that was used to compute their IR units (the call graph or LoopInfo). And for transformations, they may want to communicate special update information to the outer pass manager. With this change, it becomes possible to have a run method for a loop pass that looks more like: PreservedAnalyses run(Loop &L, AnalysisManager<Loop, LoopInfo> &AM, LoopInfo &LI, LoopUpdateRecord &UR); And to query the analysis manager like: AM.getResult<MyLoopAnalysis>(L, LI); This makes accessing the known-available analyses convenient and clear, and it makes passing customized data structures around easy. My initial use case is going to be in updating the pass manager layers when the analysis units of IR change. But there are more use cases here such as having a layer that lets inner passes signal whether certain additional passes should be run because of particular simplifications made. Two desires for this have come up in the past: triggering additional optimization after successfully unrolling loops, and triggering additional inlining after collapsing indirect calls to direct calls. Despite adding this layer of generic extensibility, the *only* change to existing, simple usage are for places where we forward declare the AnalysisManager template. We really shouldn't be doing this because of the fragility exposed here, but currently it makes coping with the legacy PM code easier. Differential Revision: http://reviews.llvm.org/D21462 llvm-svn: 279227
* [PM] Port the always inliner to the new pass manager in a much moreChandler Carruth2016-08-172-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PM] Port LoopDataPrefetch to new pass managerTeresa Johnson2016-08-132-0/+2
| | | | | | | | | | | | | | | | 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
* [PM] Port LowerInvoke to the new pass managerMichael Kuperstein2016-08-122-0/+2
| | | | llvm-svn: 278531
* [PM] Port NameAnonFunction pass to new pass managerTeresa Johnson2016-08-122-0/+2
| | | | | | | | | | | | | | | Summary: Port the NameAnonFunction pass and add a test. Depends on D23439. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23440 llvm-svn: 278509
* [PM] Port ModuleSummaryIndex analysis to new pass managerTeresa Johnson2016-08-122-0/+2
| | | | | | | | | | | | | | | | | | | 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
* Consistently use CGSCCAnalysisManagerSean Silva2016-08-091-2/+2
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278080
* Consistently use LoopAnalysisManagerSean Silva2016-08-091-2/+2
| | | | | | | | | | | | | | | | | One exception here is LoopInfo which must forward-declare it (because the typedef is in LoopPassManager.h which depends on LoopInfo). Also, some includes for LoopPassManager.h were needed since that file provides the typedef. Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278079
* Consistently use ModuleAnalysisManagerSean Silva2016-08-091-2/+2
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278078
* Consistently use FunctionAnalysisManagerSean Silva2016-08-091-2/+2
| | | | | | | | | | | Besides a general consistently benefit, the extra layer of indirection allows the mechanical part of https://reviews.llvm.org/D23256 that requires touching every transformation and analysis to be factored out cleanly. Thanks to David for the suggestion. llvm-svn: 278077
* [PM] Change the name of the repeating utility to something lessChandler Carruth2016-08-041-4/+4
| | | | | | | | | | | overloaded (and simpler). Sean rightly pointed out in code review that we've started using "wrapper pass" as a specific part of the old pass manager, and in fact it is more applicable there. Here, we really have a pass *template* to build a repeated pass, so call it that. llvm-svn: 277689
* [PM] Fix a mis-named parameter in parseLoopPass -- the pass manager wasChandler Carruth2016-08-031-6/+6
| | | | | | | called "FPM" instead of "LPM" in a hold-over from when the code was modeled on that used to parse function passes. llvm-svn: 277584
* [PM] Add a generic 'repeat N times' pass wrapper to the new passChandler Carruth2016-08-031-1/+58
| | | | | | | | | | | | | | | | | | | | | | | | manager. While this has some utility for debugging and testing on its own, it is primarily intended to demonstrate the technique for adding custom wrappers that can provide more interesting interation behavior in a nice, orthogonal, and composable layer. Being able to write these kinds of very dynamic and customized controls for running passes was one of the motivating use cases of the new pass manager design, and this gives a hint at how they might look. The actual logic is tiny here, and most of this is just wiring in the pipeline parsing so that this can be widely used. I'm adding this now to show the wiring without a lot of business logic. This is a precursor patch for showing how a "iterate up to N times as long as we devirtualize a call" utility can be added as a separable and composable component along side the CGSCC pass management. Differential Revision: https://reviews.llvm.org/D22405 llvm-svn: 277581
* [PM] Remove the NDEBUG condition around isModulePassName.Chandler Carruth2016-08-031-2/+0
| | | | | | | | I forgot to do this initially, and added when I saw this fail in a no-asserts build, but managed to loose the diff from the actual patch that got submitted. Very sorry. llvm-svn: 277562
* [PM] Significantly refactor the pass pipeline parsing to be easier toChandler Carruth2016-08-031-244/+247
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reason about and less error prone. The core idea is to fully parse the text without trying to identify passes or structure. This is done with a single state machine. There were various bugs in the logic around this previously that were repeated and scattered across the code. Having a single routine makes it much easier to fix and get correct. For example, this routine doesn't suffer from PR28577. Then the actual pass construction is handled using *much* easier to read code and simple loops, with particular pass manager construction sunk to live with other pass construction. This is especially nice as the pass managers *are* in fact passes. Finally, the "implicit" pass manager synthesis is done much more simply by forming "pre-parsed" structures rather than having to duplicate tons of logic. One of the bugs fixed by this was evident in the tests where we accepted a pipeline that wasn't really well formed. Another bug is PR28577 for which I have added a test case. The code is less efficient than the previous code but I'm really hoping that's not a priority. ;] Thanks to Sean for the review! Differential Revision: https://reviews.llvm.org/D22724 llvm-svn: 277561
* [PM] Port SpeculativeExecution to the new PMMichael Kuperstein2016-08-012-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D23033 llvm-svn: 277393
* [PM] Port LowerGuardIntrinsic to the new PM.Michael Kuperstein2016-07-282-0/+2
| | | | llvm-svn: 277057
* [PM] Port SymbolRewriter to the new PMMichael Kuperstein2016-07-252-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D22703 llvm-svn: 276687
* StringSwitch cannot be copied (take 2).Jordan Rose2016-07-251-7/+7
| | | | | | | | | | | | | | | | | | | | This prevents StringSwitch from being used with 'auto', which is important because the inferred type is StringSwitch rather than the result type. This is a problem because StringSwitch stores addresses of temporary values rather than copying or moving the value into its own storage. This is a compromise that still allows wrapping StringSwitch in other temporary structures, which (unlike StringSwitch) may be non-trivial to set up and therefore want to at least be movable. (For an example, see QueryParser.cpp in clang-tools-extra.) Changing this uncovered the bug in PassBuilder, also in this patch. Clang doesn't seem to have any occurrences of the issue. Re-commit of r276652. llvm-svn: 276671
* Revert "StringSwitch cannot be copied or moved."Jordan Rose2016-07-251-7/+7
| | | | | | | This reverts commit r276652. The clang-query tool is currently relying on this behavior. I'll try again later. llvm-svn: 276661
* StringSwitch cannot be copied or moved.Jordan Rose2016-07-251-7/+7
| | | | | | | | | | | | ...but most importantly, it cannot be used well with 'auto', because the inferred type is StringSwitch rather than the result type. This is a problem because StringSwitch stores addresses of temporary values rather than copying or moving the value into its own storage. Changing this uncovered the bug in PassBuilder, also in this patch. Clang doesn't seem to have any occurrences of the issue. llvm-svn: 276652
* [PM] Port BreakCriticalEdges to the new PM.Wei Mi2016-07-222-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D22688 llvm-svn: 276449
* [PM] Port NaryReassociate to the new PMWei Mi2016-07-212-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D22648 llvm-svn: 276349
* [PM] Port LoopUnroll.Sean Silva2016-07-192-0/+3
| | | | | | | | | 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
* [PM] Convert Loop Strength Reduce pass to new PMDehao Chen2016-07-182-0/+2
| | | | | | | | | | | | 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
* [PM] Port FunctionImport Pass to new PMTeresa Johnson2016-07-182-0/+2
| | | | | | | | | | | | 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
* [LoopDist] Port to new PMAdam Nemet2016-07-182-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* [OptRemarkEmitter] Port to new PMAdam Nemet2016-07-182-0/+2
| | | | | | | | | | | | | | | | | | | | 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
* Sort include headersAdam Nemet2016-07-181-1/+1
| | | | llvm-svn: 275809
* [PM] Convert IVUsers analysis to new pass manager.Dehao Chen2016-07-162-0/+3
| | | | | | | | | | | | 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
* [PM] Convert LoopInstSimplify Pass to new PMDehao Chen2016-07-152-0/+2
| | | | | | | | | | | | 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
* code hoisting pass based on GVNSebastian Pop2016-07-151-0/+1
| | | | | | | | | | | | | 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
* [PM] Port Dead Loop Deletion Pass to the new PMJun Bum Lim2016-07-142-0/+2
| | | | | | | | | | | | 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
* Revert r275401, it caused PR28551.Nico Weber2016-07-141-1/+0
| | | | llvm-svn: 275420
* code hoisting pass based on GVNSebastian Pop2016-07-141-0/+1
| | | | | | | | | | | | | 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: 275401
* Add missing files for r275222Dehao Chen2016-07-122-0/+2
| | | | | | | | | | | | | | 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
* [PM] Port LoopIdiomRecognize Pass to new PMDehao Chen2016-07-122-0/+2
| | | | | | | | | | | | 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
* Revert "New pass manager for LICM."Vitaly Buka2016-07-122-2/+0
| | | | | | | | | | Summary: This reverts commit r275118. Subscribers: sanjoy, mehdi_amini Differential Revision: http://reviews.llvm.org/D22259 llvm-svn: 275156
* New pass manager for LICM.Dehao Chen2016-07-112-0/+2
| | | | | | | | | | | | Summary: Port LICM to the new pass manager. Reviewers: davidxl, silvas Subscribers: silvas, davide, sanjoy, llvm-commits, mehdi_amini Differential Revision: http://reviews.llvm.org/D21772 llvm-svn: 275118
* [PM/IPO] Port LowerTypeTests to the new PassManager.Davide Italiano2016-07-112-0/+2
| | | | | | | | 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
* [PM] Port LoopVectorize to the new PM.Sean Silva2016-07-092-0/+2
| | | | llvm-svn: 275000
* [PM] Port CrossDSOCFI to the new pass manager.Davide Italiano2016-07-092-0/+2
| | | | llvm-svn: 274962
* [PM] Fix a think-o. mv {Scalar,Vectorize}/SLPVectorize.hSean Silva2016-07-091-1/+1
| | | | llvm-svn: 274960
* [PM] Port LoopSimplify to the new pass manager.Davide Italiano2016-07-092-0/+2
| | | | | | | | | 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
* [PM] name the new PM LAA class LoopAccessAnalysis (LAA) /NFCXinliang David Li2016-07-081-1/+1
| | | | llvm-svn: 274934
* [PM] Port UnreachableBlockElim to the new Pass ManagerWei Mi2016-07-082-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D22124 llvm-svn: 274824
* [PM] Port InstSimplify to the new pass manager.Davide Italiano2016-07-072-0/+2
| | | | llvm-svn: 274796
* [PM] Port TailCallElimSean Silva2016-07-062-0/+2
| | | | llvm-svn: 274708
* [PM] Port CorrelatedValuePropagationSean Silva2016-07-062-0/+2
| | | | llvm-svn: 274705
OpenPOWER on IntegriCloud