summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/fsub.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] add tests for fsub; NFCSanjay Patel2020-01-101-0/+135
| | | | | Conflicting/missing canonicalizations are visible in PR44509: https://bugs.llvm.org/show_bug.cgi?id=44509
* [InstCombine] canonicalize fneg before fmul/fdivSanjay Patel2019-07-311-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it easier to implement the transforms (and possibly other fneg transforms) in 1 place because we can always start the pattern match from fneg (either the legacy binop or the new unop). There's a secondary practical benefit seen in PR21914 and PR42681: https://bugs.llvm.org/show_bug.cgi?id=21914 https://bugs.llvm.org/show_bug.cgi?id=42681 ...hoisting fneg rather than sinking seems to play nicer with LICM in IR (although this change may expose analysis holes in the other direction). 1. The instcombine test changes show the expected neutral IR diffs from reversing the order. 2. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because: "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result." In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?) 3. The clang tests shouldn't exist as-is, but that's effectively a revert of rL367149 (the test broke with an extension of the pre-existing fneg canonicalization in rL367146). Differential Revision: https://reviews.llvm.org/D65399 llvm-svn: 367447
* [InstCombine] fold fsub+fneg with fdiv/fmul betweenSanjay Patel2019-07-281-8/+8
| | | | | | | | | The backend already does this via isNegatibleForFree(), but we may want to alter the fneg IR canonicalizations that currently exist, so we need to try harder to fold fneg in IR to avoid regressions. llvm-svn: 367194
* [InstCombine] add tests for fsub with negated operand; NFCSanjay Patel2019-07-261-0/+237
| | | | llvm-svn: 367156
* [InstCombine] Handle -(X-Y) --> (Y-X) for unary fneg when NSZCameron McInally2019-06-111-3/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D62612 llvm-svn: 363082
* [InstCombine] Update fptrunc (fneg x)) -> (fneg (fptrunc x) for unary FNegCameron McInally2019-06-111-4/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D62629 llvm-svn: 363080
* [NFC][InstCombine] Add a unary FNeg test to fsub.ll.Cameron McInally2019-05-291-0/+11
| | | | llvm-svn: 361988
* [NFC][InstCombine] Add unary FNeg tests to fsub.ll known-never-nan.llCameron McInally2019-05-291-0/+127
| | | | llvm-svn: 361971
* Add FNeg IR constant folding supportCameron McInally2019-05-051-3/+3
| | | | llvm-svn: 359982
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+271
| | | | | | | | 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-171-271/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [InstCombine] fold fneg into constant operand of fmul/fdivSanjay Patel2018-08-081-5/+5
| | | | | | | | | | | | This accounts for the missing IR fold noted in D50195. We don't need any fast-math to enable the negation transform. FP negation can always be folded into an fmul/fdiv constant to eliminate the fneg. I've limited this to one-use to ensure that we are eliminating an instruction rather than replacing fneg by a potentially expensive fdiv or fmul. Differential Revision: https://reviews.llvm.org/D50417 llvm-svn: 339248
* [NFC] adding tests for Y - (X + Y) --> -XMichael Berg2018-08-071-0/+13
| | | | llvm-svn: 339197
* [InstCombine] don't negate constant expression with fsub (PR37605)Sanjay Patel2018-05-301-0/+14
| | | | | | | X + (-C) would be transformed back into X - C, so infinite loop: https://bugs.llvm.org/show_bug.cgi?id=37605 llvm-svn: 333610
* [InstCombine] limit X - (cast(-Y) --> X + cast(Y) with hasOneUse()Sanjay Patel2018-04-111-8/+5
| | | | llvm-svn: 329821
* [InstCombine] add/move tests for fsub folds; NFCSanjay Patel2018-04-071-1/+100
| | | | | | | | There are a pair of folds that try to merge fneg into fsub with an intervening cast, but as shown in the FIXME tests, they can create extra instructions. llvm-svn: 329501
* [InstCombine] limit nsz: -(X - Y) --> Y - X to hasOneUse()Sanjay Patel2018-04-061-3/+7
| | | | | | | As noted in the post-commit discussion for r329350, we shouldn't generally assume that fsub is the same cost as fneg. llvm-svn: 329429
* [InstCombine] add test for fsub+fneg with extra use; NFCSanjay Patel2018-04-061-0/+15
| | | | llvm-svn: 329418
* [InstCombine] FP: Z - (X - Y) --> Z + (Y - X)Sanjay Patel2018-04-051-6/+6
| | | | | | | | | | | | This restores what was lost with rL73243 but without re-introducing the bug that was present in the old code. Note that we already have these transforms if the ops are marked 'fast' (and I assume that's happening somewhere in the code added with rL170471), but we clearly don't need all of 'fast' for these transforms. llvm-svn: 329362
* [InstCombine] add FP tests for Z - (X - Y); NFCSanjay Patel2018-04-051-3/+29
| | | | | | | | A fold for this pattern was removed at rL73243 to fix PR4374: https://bugs.llvm.org/show_bug.cgi?id=4374 ...and apparently there were no tests that went with that fold. llvm-svn: 329360
* [InstCombine] nsz: -(X - Y) --> Y - XSanjay Patel2018-04-051-2/+1
| | | | | | This restores part of the fold that was removed with rL73243 (PR4374). llvm-svn: 329350
* [InstCombine] add test for fneg+fsub with nsz; NFCSanjay Patel2018-04-051-3/+17
| | | | | | | | There used to be a fold that would handle this case more generally, but it was removed at rL73243 to fix PR4374: https://bugs.llvm.org/show_bug.cgi?id=4374 llvm-svn: 329322
* [InstCombine] use pattern matchers for fsub --> fadd foldsSanjay Patel2018-04-051-3/+2
| | | | | | This allows folding for vectors with undef elements. llvm-svn: 329316
* [InstCombine] add tests for fsub --> fadd; NFCSanjay Patel2018-04-051-3/+65
| | | | llvm-svn: 329313
* [InstSimplify] fp_binop X, undef --> NaNSanjay Patel2018-03-101-20/+0
| | | | | | The variable operand could be NaN, so it's always safe to propagate NaN. llvm-svn: 327212
* [ConstantFold] fp_binop AnyConstant, undef --> NaNSanjay Patel2018-03-101-28/+0
| | | | | | | | | | | | | | | | | | With the updated LangRef ( D44216 / rL327138 ) in place, we can proceed with more constant folding. I'm intentionally taking the conservative path here: no matter what the constant or the FMF, we can always fold to NaN. This is because the undef operand can be chosen as NaN, and in our simplified default FP env, nothing else happens - NaN just propagates to the result. If we find some way/need to propagate undef instead, that can be added subsequently. The tests show that we always choose the same quiet NaN constant (0x7FF8000000000000 in IR text). There were suggestions to improve that with a 'NaN' string token or not always print a 64-bit hex value, but those are independent changes. We might also consider setting/propagating the payload of NaN constants as an enhancement. Differential Revision: https://reviews.llvm.org/D44308 llvm-svn: 327208
* [InstCombine] regenerate checks; NFCSanjay Patel2018-03-081-23/+33
| | | | | | | We may not need any of these tests after rL327012, but leaving them here for now until that's confirmed. llvm-svn: 327014
* InstCombine: Fix assert when reassociating fsub with undefMatt Arsenault2017-04-241-0/+44
| | | | | | | | | | | | | There is logic to track the expected number of instructions produced. It thought in this case an instruction would be necessary to negate the result, but here it folded into a ConstantExpr fneg when the non-undef value operand was cancelled out by the second fsub. I'm not sure why we don't fold constant FP ops with undef currently, but I think that would also avoid this problem. llvm-svn: 301199
* Reduce fsub-fadd.ll and merge it into fsub-fsub.ll. Rename fsub-fsub.ll toBill Wendling2010-01-171-0/+23
fsub.ll and FileCheckify it. llvm-svn: 93669
OpenPOWER on IntegriCloud