summaryrefslogtreecommitdiffstats
path: root/llvm/test/Other/pass-pipelines.ll
Commit message (Collapse)AuthorAgeFilesLines
* [LoopRotate] Get and update MSSA only if available in legacy pass manager.Alina Sbirlea2020-02-261-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Potential fix for: https://bugs.llvm.org/show_bug.cgi?id=44889 and https://bugs.llvm.org/show_bug.cgi?id=44408 In the legacy pass manager, loop rotate need not compute MemorySSA when not being in the same loop pass manager with other loop passes. There isn't currently a way to differentiate between the two cases, so this attempts to limit the usage in LoopRotate to only update MemorySSA when the analysis is already available. The side-effect of this is that it will split the Loop pipeline. This issue does not apply to the new pass manager, where we have a flag specifying if all loop passes in that loop pass manager preserve MemorySSA. Reviewers: dmgreen, fedor.sergeev, nikic Subscribers: Prazek, hiraditya, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74574 (cherry picked from commit 1326a5a4cfe004181f2ec8231d84ecda2b93cb25)
* [LegacyPM] Fix pass structure dumpingevgeny2019-11-011-1/+1
| | | | | | | | If module pass uses on-demand function analyses then structure is being displayed incorrectly because FunctionPassManagerImpl can't dump contained FPPassManager instances. Differential revision: https://reviews.llvm.org/D69315
* Revert '[LICM] Make Loop ICM profile aware' and 'Fix pass dependency for LICM'David L. Jones2019-08-141-1/+1
| | | | | | | This reverts r368526 (git commit 7e71aa24bc0788690fea7f0d7eab400c6a784deb) This reverts r368542 (git commit cb5a90fd314a7914cf293797bb4fd7a6841052cf) llvm-svn: 368800
* [LICM] Make Loop ICM profile awareWenlei He2019-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Hoisting/sinking instruction out of a loop isn't always beneficial. Hoisting an instruction from a cold block inside a loop body out of the loop could hurt performance. This change makes Loop ICM profile aware - it now checks block frequency to make sure hoisting/sinking anly moves instruction to colder block. Test Plan: ninja check Reviewers: asbirlea, sanjoy, reames, nikic, hfinkel, vsk Reviewed By: asbirlea Subscribers: fhahn, vsk, davidxl, xbolva00, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65060 llvm-svn: 368526
* [HotColdSplit] Schedule splitting late to fix perf regressionVedant Kumar2019-02-151-1/+1
| | | | | | | | | | | | | | | With or without PGO data applied, splitting early in the pipeline (either before the inliner or shortly after it) regresses performance across SPEC variants. The cause appears to be that splitting hides context for subsequent optimizations. Schedule splitting late again, in effect reversing r352080, which scheduled the splitting pass early for code size benefits (documented in https://reviews.llvm.org/D57082). Differential Revision: https://reviews.llvm.org/D58258 llvm-svn: 354158
* [HotColdSplit] Move splitting after instrumented PGO useTeresa Johnson2019-02-061-0/+16
| | | | | | | | | | | | | | | | | | | | | Summary: Follow up to D57082 which moved splitting earlier in the pipeline, in order to perform it before inlining. However, it was moved too early, before the IR is annotated with instrumented PGO data. This caused the splitting to incorrectly determine cold functions. Move it to just after PGO annotation (still before inlining), in both pass managers. Reviewers: vsk, hiraditya, sebpop Subscribers: mehdi_amini, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57805 llvm-svn: 353270
* Re-commit : [PowerPC] Add handling for ColdCC calling convention and a pass ↵Zaara Syeda2018-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | to mark candidates with coldcc attribute. This recommits r322721 reverted due to sanitizer memory leak build bot failures. Original commit message: This patch adds support for the coldcc calling convention for Power. This changes the set of non-volatile registers. It includes a pass to stress test the implementation by marking all static directly called functions with the coldcc attribute through the option -enable-coldcc-stress-test. It also includes an option, -ppc-enable-coldcc, to add the coldcc attribute to functions which are cold at all call sites based on BlockFrequencyInfo when the containing function does not call any non cold functions. Differential Revision: https://reviews.llvm.org/D38413 llvm-svn: 323778
* Revert [PowerPC] This reverts commit rL322721Zaara Syeda2018-01-171-1/+1
| | | | | | Failing build bots. Revert the commit now. llvm-svn: 322748
* [PowerPC] Add handling for ColdCC calling convention and a pass to markZaara Syeda2018-01-171-1/+1
| | | | | | | | | | | | | | | | candidates with coldcc attribute. This patch adds support for the coldcc calling convention for Power. This changes the set of non-volatile registers. It includes a pass to stress test the implementation by marking all static directly called functions with the coldcc attribute through the option -enable-coldcc-stress-test. It also includes an option, -ppc-enable-coldcc, to add the coldcc attribute to functions which are cold at all call sites based on BlockFrequencyInfo when the containing function does not call any non cold functions. Differential Revision: https://reviews.llvm.org/D38413 llvm-svn: 322721
* [PassManager] Improve the interaction between -O2 and ThinLTO.Davide Italiano2017-10-051-3/+3
| | | | | | | Run GDCE slightly later so that we don't have to repeat it twice when preparing for Thin. Thanks to Mehdi for the suggestion. llvm-svn: 314999
* [PassManager] Run global optimizations after the inliner.Davide Italiano2017-10-051-0/+2
| | | | | | | | | | | | | | | The inliner performs some kind of dead code elimination as it goes, but there are cases that are not really caught by it. We might at some point consider teaching the inliner about them, but it is OK for now to run GlobalOpt + GlobalDCE in tandem as their benefits generally outweight the cost, making the whole pipeline faster. This fixes PR34652. Differential Revision: https://reviews.llvm.org/D38154 llvm-svn: 314997
* fix typos in comments; NFCHiroshi Inoue2017-07-111-1/+1
| | | | llvm-svn: 307626
* Simplify the CFG after loop pass cleanup.Filipe Cabecinhas2017-04-261-0/+1
| | | | | | | | | | | | | | | | Summary: Otherwise we might end up with some empty basic blocks or single-entry-single-exit basic blocks. This fixes PR32085 Reviewers: chandlerc, danielcdh Subscribers: mehdi_amini, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D30468 llvm-svn: 301395
* Enable Loop Sink pass for functions that has profile.Dehao Chen2016-11-091-0/+3
| | | | | | | | | | | | Summary: For functions with profile data, we are confident that loop sink will be optimal in sinking code. Reviewers: davidxl, hfinkel Subscribers: mehdi_amini, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D26155 llvm-svn: 286325
* Move "Eliminate Available Externally" immediately after the inlinerMehdi Amini2016-05-031-1/+4
| | | | | | | | | | | This pass is supposed to reduce the size of the IR for compile time purpose. We should run it ASAP, except when we prepare for LTO or ThinLTO, and we want to keep them available for link-time inline. Differential Revision: http://reviews.llvm.org/D19813 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268394
* Move createReversePostOrderFunctionAttrsPass right after the inliner is doneMehdi Amini2016-05-021-0/+3
| | | | | | | | | | This is where it was originally, until LoopVersioningLICM was inserted before in r259986, I don't believe it was on purpose. Differential Revision: http://reviews.llvm.org/D19809 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 268252
* [LPM] Factor all of the loop analysis usage updates into a common helperChandler Carruth2016-02-191-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | routine. We were getting this wrong in small ways and generally being very inconsistent about it across loop passes. Instead, let's have a common place where we do this. One minor downside is that this will require some analyses like SCEV in more places than they are strictly needed. However, this seems benign as these analyses are complete no-ops, and without this consistency we can in many cases end up with the legacy pass manager scheduling deciding to split up a loop pass pipeline in order to run the function analysis half-way through. It is very, very annoying to fix these without just being very pedantic across the board. The only loop passes I've not updated here are ones that use AU.setPreservesAll() such as IVUsers (an analysis) and the pass printer. They seemed less relevant. With this patch, almost all of the problems in PR24804 around loop pass pipelines are fixed. The one remaining issue is that we run simplify-cfg and instcombine in the middle of the loop pass pipeline. We've recently added some loop variants of these passes that would seem substantially cleaner to use, but this at least gets us much closer to the previous state. Notably, the seven loop pass managers is down to three. I've not updated the loop passes using LoopAccessAnalysis because that analysis hasn't been fully wired into LoopSimplify/LCSSA, and it isn't clear that those transforms want to support those forms anyways. They all run late anyways, so this is harmless. Similarly, LSR is left alone because it already carefully manages its forms and doesn't need to get fused into a single loop pass manager with a bunch of other loop passes. LoopReroll didn't use loop simplified form previously, and I've updated the test case to match the trivially different output. Finally, I've also factored all the pass initialization for the passes that use this technique as well, so that should be done regularly and reliably. Thanks to James for the help reviewing and thinking about this stuff, and Ben for help thinking about it as well! Differential Revision: http://reviews.llvm.org/D17435 llvm-svn: 261316
* [LPM] Actually test what the O2 pass pipeline consists of in key places,Chandler Carruth2016-02-191-0/+101
especially the *structure* of it with respect to various pass managers. This uncovers an absolute horror show of problems. This test shows just how bad PR24804 is: we have a totaly of *seven* loop pass managers in the main optimization pipeline. I've tried to comment the various bits to the best of my knowledge, but more enhancements here would be great. Also great would be folks adding various test for other pipelines, I'm focused on trying to fix the O2 pipeline. I just wanted a test to show what I'm changing. llvm-svn: 261305
OpenPOWER on IntegriCloud