summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/DivRemPairs
Commit message (Collapse)AuthorAgeFilesLines
* [DivRemPairs] Don't assert that we won't ever get expanded-form rem pairs in ↵Roman Lebedev2019-09-291-0/+36
| | | | | | | | | | | | | different BB's (PR43500) If we happen to have the same div in two basic blocks, and in one of those we also happen to have the rem part, we'd match the div-rem pair, but the wrong ones. So let's drop overly-ambiguous assert. Fixes https://bugs.llvm.org/show_bug.cgi?id=43500 llvm-svn: 373167
* [DivRemPairs] Recommit: Handling for expanded-form rem - recomposition (PR42673)Roman Lebedev2019-07-312-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair is unsupported by target, nothing performs the opposite fold. We can't do that in InstCombine or DAGCombine since neither of those has access to TTI. So it makes most sense to teach `-div-rem-pairs` about it. If we matched rem in expanded form, we know we will be able to place div-rem pair next to each other so we won't regress the situation. Also, we shouldn't decompose rem if we matched already-decomposed form. This is surprisingly straight-forward otherwise. The original patch was committed in rL367288 but was reverted in rL367289 because it exposed pre-existing RAUW issues in internal data structures of the pass; those now have been addressed in a previous patch. https://bugs.llvm.org/show_bug.cgi?id=42673 Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner Reviewed By: bogner Subscribers: bogner, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65298 llvm-svn: 367419
* [DivRemPairs] Avoid RAUW pitfalls (PR42823)Roman Lebedev2019-07-313-26/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `DivRemPairs` internally creates two maps: * {sign, divident, divisor} -> div instruction * {sign, divident, divisor} -> rem instruction Then it iterates over rem map, and looks if there is an entry in div map with the same key. Then depending on some internal logic it may RAUW rem instruction with something else. But if that rem instruction is an input to other div/rem, then it was used as a key in these maps, so the old value (used in key) is now dandling, because RAUW didn't update those maps. And we can't even RAUW map keys in general, there's `ValueMap`, but we don't have a single `Value` as key... The bug was discovered via D65298, and the test there exists. Now, i'm not sure how to expose this issue in trunk. The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`, but i guess this didn't miscompiled anything thus far? I really don't think this is benin without that patch. The fix is actually rather straight-forward - instead of trying to somehow shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new `ValueMap` with key being a struct of `Value`s, we can just have an intermediate data structure - a vector, each entry containing matching `Div, Rem` pair, and pre-filling it before doing any modifications. This way we won't need to query map after doing RAUW, so no bug is possible. Reviewers: spatel, bogner, RKSimon, craig.topper Reviewed By: spatel Subscribers: hiraditya, hans, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65451 llvm-svn: 367417
* [DivRemPairs][NFC] Autogenerate all checklinesRoman Lebedev2019-07-314-132/+134
| | | | llvm-svn: 367415
* [DivRemPairs] Add srem-of-srem tests (PR42823, D65298, D65451)Roman Lebedev2019-07-304-0/+176
| | | | | | | | | | | | The @srem_of_srem_expanded case exposed a RAUW pitfall in D65298. Right now these don't appear to fail verification, so it should be safe to precommit them. https://reviews.llvm.org/D65298 https://bugs.llvm.org/show_bug.cgi?id=42823 https://reviews.llvm.org/D65451 llvm-svn: 367325
* Revert "[DivRemPairs] Handling for expanded-form rem - recomposition (PR42673)"Roman Lebedev2019-07-301-4/+4
| | | | | | | | | | | test-suite/MultiSource/Benchmarks/DOE-ProxyApps-C/miniGMG broke: Only PHI nodes may reference their own value! %sub33 = srem i32 %sub33, %ranks_in_i This reverts commit r367288. llvm-svn: 367289
* [DivRemPairs] Handling for expanded-form rem - recomposition (PR42673)Roman Lebedev2019-07-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While `-div-rem-pairs` pass can decompose rem in div+rem pair when div-rem pair is unsupported by target, nothing performs the opposite fold. We can't do that in InstCombine or DAGCombine since neither of those has access to TTI. So it makes most sense to teach `-div-rem-pairs` about it. If we matched rem in expanded form, we know we will be able to place div-rem pair next to each other so we won't regress the situation. Also, we shouldn't decompose rem if we matched already-decomposed form. This is surprisingly straight-forward otherwise. https://bugs.llvm.org/show_bug.cgi?id=42673 Reviewers: spatel, RKSimon, efriedma, ZaMaZaN4iK, bogner Reviewed By: bogner Subscribers: bogner, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65298 llvm-svn: 367288
* [NFC][DivRemPairs] Tests with rem in expanded form (PR42673)Roman Lebedev2019-07-252-0/+254
| | | | | | | | | | | | | | | | | | | As discussed in https://bugs.llvm.org/show_bug.cgi?id=42673 there is a TTI hook hasDivRemOp() that matters here. While -div-rem-pairs will decompose 'rem' if that hook returns false, nothing does the opposite transform. We can't to this in InstCombine, because it does not currently access TTI, and i'm not sure we should change that. We can't really do that in DAGCombine since it also currently does not access TTI. Therefore only DivRemPairs is left. https://bugs.llvm.org/show_bug.cgi?id=42673 llvm-svn: 367046
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-172-2/+0
| | | | llvm-svn: 363538
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-174-0/+606
| | | | | | | | The reversion apparently deleted the test/Transforms directory. Will be re-reverting again. llvm-svn: 358552
* Temporarily Revert "Add basic loop fusion pass."Eric Christopher2019-04-174-606/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [DivRemPairs] split tests per target to account for bots that don't build ↵Sanjay Patel2017-09-095-364/+606
| | | | | | for all targets llvm-svn: 312863
* [DivRempairs] add a pass to optimize div/rem pairs (PR31028)Sanjay Patel2017-09-091-0/+364
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