summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/fabs.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] allow unordered preds when canonicalizing to fabs()Sanjay Patel2019-06-101-8/+4
| | | | | | | | | | We have a known-never-nan value via 'nnan', so an unordered predicate is the same as its ordered sibling. Similar to: rL362937 llvm-svn: 362954
* [InstCombine] add tests for fabs() with unordered preds; NFCSanjay Patel2019-06-101-0/+30
| | | | llvm-svn: 362949
* [InstCombine] fix bug in canonicalization to fabs()Sanjay Patel2019-06-101-0/+30
| | | | | | Forgot to translate the predicate clauses in rL362943. llvm-svn: 362945
* [InstCombine] change canonicalization to fabs() to use FMF on fsubSanjay Patel2019-06-101-8/+8
| | | | | | | | | | | | | | Similar to rL362909: This isn't the ideal fix (use FMF on the select), but it's still an improvement until we have better FMF propagation to selects and other FP math operators. I don't think there's much risk of regression from this change by not including the FMF on the fcmp any more. The nsz/nnan FMF should be the same on the fcmp and the fsub because they have the same operand. llvm-svn: 362943
* [InstCombine] allow unordered preds when canonicalizing to fabs()Sanjay Patel2019-06-101-60/+30
| | | | | | | PR42179: https://bugs.llvm.org/show_bug.cgi?id=42179 llvm-svn: 362937
* [InstCombine] add tests for fcmp unordered pred -> fabs (PR42179); NFCSanjay Patel2019-06-101-0/+225
| | | | llvm-svn: 362936
* [InstCombine] change canonicalization to fabs() to use FMF on fnegSanjay Patel2019-06-091-30/+30
| | | | | | | | | | | | | | | | | This isn't the ideal fix (use FMF on the select), but it's still an improvement until we have better FMF propagation to selects and other FP math operators. I don't think there's much risk of regression from this change by not including the FMF on the fcmp any more. The nsz/nnan FMF should be the same on the fcmp and the fneg (fsub) because they have the same operand. This works around the most glaring FMF logical inconsistency cited in PR38086: https://bugs.llvm.org/show_bug.cgi?id=38086 llvm-svn: 362909
* [NFC][InstCombine] Add unary FNeg tests to fabs.llCameron McInally2019-05-311-0/+76
| | | | llvm-svn: 362238
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+420
| | | | | | | | 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-420/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [PatternMatch] allow undef elements when matching vector FP +0.0Sanjay Patel2018-03-251-4/+2
| | | | | | | | | | | | | This continues the FP constant pattern matching improvements from: https://reviews.llvm.org/rL327627 https://reviews.llvm.org/rL327339 https://reviews.llvm.org/rL327307 Several integer constant matchers also have this ability. I'm separating matching of integer/pointer null from FP positive zero and renaming/commenting to make the functionality clearer. llvm-svn: 328461
* [InstSimplify, InstCombine] add/update tests with FP +0.0 vector with undef; NFCSanjay Patel2018-03-251-8/+10
| | | | llvm-svn: 328455
* [InstCombine] canonicalize fcmp+select to fabsSanjay Patel2018-03-191-68/+60
| | | | | | | | | | | | | | This is complicated by -0.0 and nan. This is based on the DAG patterns as shown in D44091. I'm hoping that we can just remove those DAG folds and always rely on IR canonicalization to handle the matching to fabs. We would still need to delete the broken code from DAGCombiner to fix PR36600: https://bugs.llvm.org/show_bug.cgi?id=36600 Differential Revision: https://reviews.llvm.org/D44550 llvm-svn: 327858
* [InstCombine] add nnan requirement to potential fabs folds tests; NFCSanjay Patel2018-03-161-20/+20
| | | | | | | As noted in D44550, we can't guarantee preserving the sign-bit of NaN if we convert these to fabs(). llvm-svn: 327718
* [InstCombine] add more tests for fcmp+select -> fabs; NFCSanjay Patel2018-03-161-11/+160
| | | | | | | This should correspond to the patterns in D44091 and might make handling these in the DAG unnecessary. llvm-svn: 327689
* [InstCombine] add tests for fcmp+select -> fabs; NFCSanjay Patel2018-03-151-24/+57
| | | | llvm-svn: 327680
* [InstCombine] regenerate test checks; NFCSanjay Patel2017-11-161-82/+97
| | | | llvm-svn: 318416
* SimplifyLibCalls: Replace fabs libcalls with intrinsicsMatt Arsenault2017-01-171-30/+45
| | | | | | | | Add missing fabs(fpext) optimzation that worked with the call, and also fixes it creating a second fpext when there were multiple uses. llvm-svn: 292172
* InstSimplify: Eliminate fabs on known positiveMatt Arsenault2017-01-111-3/+47
| | | | llvm-svn: 291624
* SimplifyLibCalls: Remove incorrect optimization of fabsMatt Arsenault2017-01-071-9/+33
| | | | | | | | fabs(x * x) is not generally safe to assume x is positive if x is a NaN. This is also less general than it could be, so this will be replaced with a transformation on the intrinsic. llvm-svn: 291359
* InstCombine: Fold fabs on select of constantsMatt Arsenault2017-01-031-0/+48
| | | | llvm-svn: 290913
* transform obscured FP sign bit ops into a fabs/fneg using TLI hookSanjay Patel2016-06-021-25/+0
| | | | | | | | | | | | | | | | | | | This is effectively a revert of: http://reviews.llvm.org/rL249702 - [InstCombine] transform masking off of an FP sign bit into a fabs() intrinsic call (PR24886) and: http://reviews.llvm.org/rL249701 - [ValueTracking] teach computeKnownBits that a fabs() clears sign bits and a reimplementation as a DAG combine for targets that have IEEE754-compliant fabs/fneg instructions. This is intended to resolve the objections raised on the dev list: http://lists.llvm.org/pipermail/llvm-dev/2016-April/098154.html and: https://llvm.org/bugs/show_bug.cgi?id=24886#c4 In the interest of patch minimalism, I've only partly enabled AArch64. PowerPC, MIPS, x86 and others can enable later. Differential Revision: http://reviews.llvm.org/D19391 llvm-svn: 271573
* [ValueTracking] teach computeKnownBits that a fabs() clears sign bitsSanjay Patel2015-10-081-0/+25
| | | | | | | | | | | | | This was requested in D13076: if we're going to canonicalize to fabs(), ValueTracking should know that fabs() clears sign bits. In this patch (as in D13076), we're not handling vectors yet even though computeKnownBits' fabs() case itself should be vector-ready via the splat in this patch. Fixing this will require follow-on patches to correct other logic that uses 'getScalarType'. Differential Revision: http://reviews.llvm.org/D13222 llvm-svn: 249701
* Optimize away fabs() calls when input is squared (known positive).Sanjay Patel2014-10-141-0/+100
Eliminate library calls and intrinsic calls to fabs when the input is a squared value. Note that no unsafe-math / fast-math assumptions are needed for this optimization. Differential Revision: http://reviews.llvm.org/D5777 llvm-svn: 219717
OpenPOWER on IntegriCloud