summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/pow-sqrt.ll
Commit message (Collapse)AuthorAgeFilesLines
* [SimplifyLibCalls] require fast-math-flags for pow(X, -0.5) transformsSanjay Patel2019-12-211-14/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in PR44330: https://bugs.llvm.org/show_bug.cgi?id=44330 ...the transform from pow(X, -0.5) libcall/intrinsic to reciprocal square root can result in small deviations from the expected result due to differences in the pow() implementation and/or the extra rounding step from the division. This patch proposes to allow that difference with either the 'approximate functions' or 'reassociate' FMF: http://llvm.org/docs/LangRef.html#fast-math-flags In practice, this likely means that the code is compiled with all of 'fast' (-ffast-math), but I have preserved the existing specializations for -0.0/-INF that enable generating safe code if those special values are allowed simultaneously with allowing approximation/reassociation. The question about whether a similar restriction is needed for the non-reciprocal case -- pow(X, 0.5) -- is deferred. That transform is allowed without FMF currently, and this patch does not change that behavior. Differential Revision: https://reviews.llvm.org/D71706
* [InstCombine] add/adjust tests for pow->sqrt; NFCSanjay Patel2019-12-191-35/+77
| | | | There's at least 1 bug here as discussed in PR44330.
* [IR] allow fast-math-flags on select of FP valuesSanjay Patel2019-05-221-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | This is a minimal start to correcting a problem most directly discussed in PR38086: https://bugs.llvm.org/show_bug.cgi?id=38086 We have been hacking around a limitation for FP select patterns by using the fast-math-flags on the condition of the select rather than the select itself. This patch just allows FMF to appear with the 'select' opcode. No changes are needed to "FPMathOperator" because it already includes select-of-FP because that definition is based on the (return) value type. Once we have this ability, we can start correcting and adding IR transforms to use the FMF on a 'select' instruction. The instcombine and vectorizer test diffs only show that the IRBuilder change is behaving as expected by applying an FMF guard value to 'select'. For reference: rL241901 - allowed FMF with fcmp rL255555 - allowed FMF with FP calls Differential Revision: https://reviews.llvm.org/D61917 llvm-svn: 361401
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+297
| | | | | | | | 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-297/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [NFC] Fix typo in test casesEvandro Menezes2018-08-161-1/+0
| | | | llvm-svn: 339900
* [InstCombine] Expand the simplification of pow(x, 0.5) to sqrt(x)Evandro Menezes2018-08-161-65/+81
| | | | | | | | | Expand the number of cases when `pow(x, 0.5)` is simplified into `sqrt(x)` by considering the math semantics with more granularity. Differential revision: https://reviews.llvm.org/D50036 llvm-svn: 339887
* [InstCombine] fix typos in tests; NFCSanjay Patel2018-08-141-6/+6
| | | | | | See D50036. llvm-svn: 339713
* [InstCombine] add tests for pow->sqrt; NFCSanjay Patel2018-08-141-26/+239
| | | | | | D50036 should fix the missed optimizations. llvm-svn: 339711
* [SLC] Refactor the simplication of pow() (NFC)Evandro Menezes2018-07-301-3/+3
| | | | | | Use more meaningful variable names. Mostly NFC. llvm-svn: 338266
* [LibCallSimplifier] allow splat vectors for pow(x, 0.5) -> sqrt() transformsSanjay Patel2017-11-191-2/+3
| | | | llvm-svn: 318629
* [LibCallSimplifier] partly fix pow(x, 0.5) -> sqrt() transformsSanjay Patel2017-11-191-4/+4
| | | | | | | | | | | | | | As the first test shows, we could transform an llvm intrinsic which never sets errno into a libcall which could set errno (even though it's marked readnone?), so that's not ideal. It's possible that we can also transform a libcall which could set errno to an intrinsic given the fast-math-flags constraint, but that's deferred to determine exactly which set of FMF are needed. Differential Revision: https://reviews.llvm.org/D40150 llvm-svn: 318628
* [InstCombine] add tests for pow(); NFCSanjay Patel2017-11-161-16/+38
| | | | | | Also, increase test diversity (and show another bug) by varying the types. llvm-svn: 318430
* [InstCombine] add tests for 'afn' FMF; NFCSanjay Patel2017-11-161-0/+21
| | | | llvm-svn: 318423
* [InstCombine] regenerate test checks; NFCSanjay Patel2017-11-161-9/+9
| | | | llvm-svn: 318420
* Replace hardcoded intrinsic list with speculatable attribute.Matt Arsenault2017-05-031-3/+6
| | | | | | No change in which intrinsics should be speculated. llvm-svn: 301995
* [SimplifyLibCalls] pow(x, -0.5) -> 1.0 / sqrt(x).Davide Italiano2017-01-091-1/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D28479 llvm-svn: 291486
* [SimplifyLibCalls] Restore the old behaviour, emit a libcall.Davide Italiano2016-08-101-1/+1
| | | | | | | | Hal pointed out that the semantic of our intrinsic and the libc call are slightly different. Add a comment while I'm here to explain why we can't emit an intrinsic. Thanks Hal! llvm-svn: 278200
* [SimplifyLibCalls] Emit sqrt intrinsic instead of a libcall.Davide Italiano2016-08-081-1/+1
| | | | llvm-svn: 277972
* [LibCallSimplifier] use instruction-level fast-math-flags to transform ↵Sanjay Patel2016-01-121-8/+6
| | | | | | | | pow(x, 0.5) calls Also, propagate the FMF to the newly created sqrt() call. llvm-svn: 257503
* [SimplifyLibCalls] New trick: pow(x, 0.5) -> sqrt(x) under -ffast-math.Davide Italiano2015-11-181-0/+15
Differential Revision: http://reviews.llvm.org/D14466 llvm-svn: 253521
OpenPOWER on IntegriCloud