Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Revert "Temporarily Revert "Add basic loop fusion pass."" | Eric Christopher | 2019-04-17 | 1 | -0/+118 |
| | | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552 | ||||
* | Temporarily Revert "Add basic loop fusion pass." | Eric Christopher | 2019-04-17 | 1 | -118/+0 |
| | | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546 | ||||
* | [New PM][IRCE] port of Inductive Range Check Elimination pass to the new ↵ | Fedor Sergeev | 2018-03-15 | 1 | -0/+1 |
| | | | | | | | | | | | | | | | | | | | | | | | | | | pass manager There are two nontrivial details here: * Loop structure update interface is quite different with new pass manager, so the code to add new loops was factored out * BranchProbabilityInfo is not a loop analysis, so it can not be just getResult'ed from within the loop pass. It cant even be queried through getCachedResult as LoopCanonicalization sequence (e.g. LoopSimplify) might invalidate BPI results. Complete solution for BPI will likely take some time to discuss and figure out, so for now this was partially solved by making BPI optional in IRCE (skipping a couple of profitability checks if it is absent). Most of the IRCE tests got their corresponding new-pass-manager variant enabled. Only two of them depend on BPI, both marked with TODO, to be turned on when BPI starts being available for loop passes. Reviewers: chandlerc, mkazantsev, sanjoy, asbirlea Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D43795 llvm-svn: 327619 | ||||
* | [IRCE] Fix corner case with Start = INT_MAX | Max Kazantsev | 2017-07-14 | 1 | -0/+117 |
When iterating through loop for (int i = INT_MAX; i > 0; i--) We fail to generate the pre-loop for it. It happens because we use the overflown value in a comparison predicate when identifying whether or not we need it. In old logic, we used SLE predicate against Greatest value which exceeds all seen values of the IV and might be overflown. Now we use the GreatestSeen value of this IV with SLT predicate. Also added a test that ensures that a pre-loop is generated for such loops. Differential Revision: https://reviews.llvm.org/D35347 llvm-svn: 308001 |