summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Passes/PassBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [PM] Port AlignmentFromAssumptions to the new PM.Sean Silva2016-06-151-0/+1
| | | | | | This uses the "runImpl" pattern to share code between the old and new PM. llvm-svn: 272757
* [PM] Port WholeProgramDevirt to the new pass manager.Davide Italiano2016-06-141-0/+1
| | | | llvm-svn: 272721
* [PM] Port Mem2Reg to the new pass manager.Davide Italiano2016-06-141-0/+2
| | | | llvm-svn: 272630
* [PM] Port MemCpyOpt to the new PM.Sean Silva2016-06-141-0/+1
| | | | | | | | | 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
* Bring back "[PM] Port JumpThreading to the new PM" with a fixSean Silva2016-06-141-0/+1
| | | | | | | | | | | 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
* [PM] Port MergedLoadStoreMotion to the new pass manager.Davide Italiano2016-06-141-1/+2
| | | | llvm-svn: 272606
* Revert "[PM] Port JumpThreading to the new PM"Sean Silva2016-06-141-1/+0
| | | | | | | | This reverts commit r272597. Will investigate issue with VS2013 compilation and then recommit. llvm-svn: 272603
* [PM] Port JumpThreading to the new PMSean Silva2016-06-131-0/+1
| | | | | | | | | | | | This follows the approach in r263208 (for GVN) pretty closely: - move the bulk of the body of the function to the new PM class. - expose a runImpl method on the new-PM class that takes the IRUnitT and pointers/references to any analyses and use that to implement the old-PM class. - use a private namespace in the header for stuff that used to be file scope llvm-svn: 272597
* [PM] Port LVI to the new PM.Sean Silva2016-06-131-0/+1
| | | | | | | | | | | | | | | | | | | 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
* [PM] Port DeadArgumentElimination to the new PMSean Silva2016-06-121-0/+1
| | | | | | | | | 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
* [PM] Port LCSSA to the new PM.Easwaran Raman2016-06-091-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D21090 llvm-svn: 272294
* [PM] Port IndVarSimplify to the new pass managerSanjoy Das2016-06-051-0/+1
| | | | | | | | | | | | | | | | | 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
* [PM] Port GCOVProfiler pass to the new pass managerXinliang David Li2016-06-051-0/+1
| | | | llvm-svn: 271823
* Reapply r271728 after adding move cobstructor for ProfileSummaryInfoEaswaran Raman2016-06-031-1/+2
| | | | llvm-svn: 271745
* Revert r271728 as it breaks Windows buildEaswaran Raman2016-06-031-2/+1
| | | | llvm-svn: 271738
* Analysis pass to access profile summary infoEaswaran Raman2016-06-031-1/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D20648 llvm-svn: 271728
* [MemorySSA] Port to new pass managerGeoff Berry2016-06-011-0/+1
| | | | | | | | | | | | | | | | | 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
* [PM] Port the Sample FDO to new PM (part-2)Xinliang David Li2016-05-271-0/+1
| | | | llvm-svn: 271072
* [PM] Port PartiallyInlineLibCalls to the new pass manager.Davide Italiano2016-05-251-0/+1
| | | | llvm-svn: 270798
* [PM] Port BDCE to the new pass manager.Davide Italiano2016-05-251-1/+2
| | | | llvm-svn: 270647
* New pass: guard wideningSanjoy Das2016-05-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PM] Port per-function SCCP to the new pass manager.Davide Italiano2016-05-181-0/+1
| | | | llvm-svn: 269937
* [PM] Port DSE to the new pass managerJustin Bogner2016-05-171-0/+1
| | | | | | Patch by JakeVanAdrighem. Thanks! llvm-svn: 269847
* Appease msc18 to move PassBuilder::crossRegisterProxies() in front of ↵NAKAMURA Takumi2016-05-161-14/+14
| | | | | | | | PassBuilder::parseModulePassPipeline(). I don't know why it crashed cl.exe but it works. llvm-svn: 269643
* [PM] Add newline at the end of the file, for consistency. NFC.Davide Italiano2016-05-141-1/+1
| | | | llvm-svn: 269583
* [PM] Refactor cross-registration of AM into an helper.Davide Italiano2016-05-141-0/+14
| | | | | | Requested by: Chandler Carruth. llvm-svn: 269582
* [PM] Port LowerAtomic to the new pass manager.Davide Italiano2016-05-131-0/+1
| | | | llvm-svn: 269511
* [PM] Port of the DepndenceAnalysis to the new PM.Chandler Carruth2016-05-121-0/+1
| | | | | | | | | | | | | 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
* [PM] port IR based PGO prof-gen pass to new pass managerXinliang David Li2016-05-061-0/+1
| | | | llvm-svn: 268710
* [PM] port Branch Frequency Analaysis pass to new PMXinliang David Li2016-05-051-0/+2
| | | | llvm-svn: 268687
* [PM] Port Interprocedural SCCP to the new pass manager.Davide Italiano2016-05-051-0/+1
| | | | llvm-svn: 268684
* [PM] Port Branch Probability Analysis pass to the new pass manager.Xinliang David Li2016-05-051-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
* [PM] Port EliminateAvailableExternally pass to the new pass manager.Davide Italiano2016-05-051-0/+1
| | | | llvm-svn: 268599
* [PM] Port ConstantMerge to the new pass manager.Davide Italiano2016-05-051-1/+2
| | | | llvm-svn: 268582
* PM: Port LoopRotation to the new loop pass managerJustin Bogner2016-05-031-0/+1
| | | | llvm-svn: 268452
* PM: Port LoopSimplifyCFG to the new pass managerJustin Bogner2016-05-031-0/+1
| | | | llvm-svn: 268446
* [IPO/GlobalDCE] Port to the new pass manager.Davide Italiano2016-05-031-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D19782 llvm-svn: 268425
* PM: Port Reassociate to the new pass managerJustin Bogner2016-04-261-0/+1
| | | | llvm-svn: 267631
* PM: Port Internalize to the new pass managerJustin Bogner2016-04-261-0/+1
| | | | llvm-svn: 267596
* PM: Port GlobalOpt to the new pass managerJustin Bogner2016-04-261-0/+1
| | | | llvm-svn: 267499
* PM: Port SinkingPass to the new pass managerJustin Bogner2016-04-221-0/+1
| | | | llvm-svn: 267199
* PM: Port DCE to the new pass managerJustin Bogner2016-04-221-0/+1
| | | | | | | 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
* Port DemandedBits to the new pass manager.Michael Kuperstein2016-04-181-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
* Port InstrProfiling pass to the new pass managerXinliang David Li2016-04-181-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D18126 llvm-svn: 266637
* [PM] Rename the CRTP mixin base classes for the new pass manager toChandler Carruth2016-03-111-8/+8
| | | | | | | | | | | | | | | | | | | | clarify their purpose. Firstly, call them "...Mixin" types so it is clear that there is no type hierarchy being formed here. Secondly, use the term 'Info' to clarify that they aren't adding any interesting *semantics* to the passes or analyses, just exposing APIs used by the management layer to get information about the pass or analysis. Thanks to Manuel for helping pin down the naming confusion here and come up with effective names to address it. In case you already have some out-of-tree stuff, the following should be roughly what you want to update: perl -pi -e 's/\b(Pass|Analysis)Base\b/\1InfoMixin/g' llvm-svn: 263217
* [PM] Implement the final conclusion as to how the analysis IDs shouldChandler Carruth2016-03-111-4/+25
| | | | | | | | | | | | | | | | | | | | work in the face of the limitations of DLLs and templated static variables. This requires passes that use the AnalysisBase mixin provide a static variable themselves. So as to keep their APIs clean, I've made these private and befriended the CRTP base class (which is the common practice). I've added documentation to AnalysisBase for why this is necessary and at what point we can go back to the much simpler system. This is clearly a better pattern than the extern template as it caught *numerous* places where the template magic hadn't been applied and things were "just working" but would eventually have broken mysteriously. llvm-svn: 263216
* [PM/AA] Teach the AAManager how to handle module analyses in addition toChandler Carruth2016-03-111-0/+7
| | | | | | | function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
* [PM] Port GVN to the new pass manager, wire it up, and teach a couple ofChandler Carruth2016-03-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CG] Add a new pass manager printer pass for the old call graph andChandler Carruth2016-03-101-0/+1
| | | | | | | | | | | | | | | | | 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
* [PM] Port memdep to the new pass manager.Chandler Carruth2016-03-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud