summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar/DivRemPairs.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reland r338431: "Add DebugCounters to DivRemPairs"George Burgess IV2018-08-011-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | (Previously reverted in r338442) I'm told that the breakage came from us using an x86 triple on configs that didn't have x86 enabled. This is remedied by moving the debugcounter test to an x86 directory (where there's also a opt-bisect-isel.ll test for similar reasons). I can't repro the reverse-iteration failure mentioned in the revert with this patch, so I assume that a misconfiguration on my end is what caused that. Original commit message: Add DebugCounters to DivRemPairs For people who don't use DebugCounters, NFCI. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50033 llvm-svn: 338653
* Revert r338431: "Add DebugCounters to DivRemPairs"George Burgess IV2018-07-311-6/+0
| | | | | | | This reverts r338431; the test it added is making buildbots unhappy. Locally, I can repro the failure on reverse-iteration builds. llvm-svn: 338442
* Add DebugCounters to DivRemPairsGeorge Burgess IV2018-07-311-0/+6
| | | | | | | | | | For people who don't use DebugCounters, NFCI. Patch by Zhizhou Yang! Differential Revision: https://reviews.llvm.org/D50033 llvm-svn: 338431
* [DivRemPairs] Fix non-determinism in use list order.Geoff Berry2018-04-251-3/+8
| | | | | | | | | | | | | | | | | Summary: Use a MapVector instead of a DenseMap for RemMap since it is iteratated over and the order of iteration can effect the order that new instructions are created. This can in turn effect the use list order of div/rem input values if multiple new instructions are created that share any input values. Reviewers: spatel Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D45858 llvm-svn: 330792
* [DivRempairs] add a pass to optimize div/rem pairs (PR31028)Sanjay Patel2017-09-091-0/+206
This is intended to be a superset of the functionality from D31037 (EarlyCSE) but implemented as an independent pass, so there's no stretching of scope and feature creep for an existing pass. I also proposed a weaker version of this for SimplifyCFG in D30910. And I initially had almost this same functionality as an addition to CGP in the motivating example of PR31028: https://bugs.llvm.org/show_bug.cgi?id=31028 The advantage of positioning this ahead of SimplifyCFG in the pass pipeline is that it can allow more flattening. But it needs to be after passes (InstCombine) that could sink a div/rem and undo the hoisting that is done here. Decomposing remainder may allow removing some code from the backend (PPC and possibly others). Differential Revision: https://reviews.llvm.org/D37121 llvm-svn: 312862
OpenPOWER on IntegriCloud