summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/fdiv.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Z / (1.0 / Y) => (Y * Z)@raghesh (Raghesh Aloor)2020-01-091-2/+2
| | | | | | | | | This is a special case of Z / (X / Y) => (Y * Z) / X, with X = 1.0. The m_OneUse check is avoided because even in the case of the multiple uses for 1.0/Y, the number of instructions remain the same and a division is replaced by a multiplication. Differential Revision: https://reviews.llvm.org/D72319
* [InstCombine] Use minimal FMF in testcase for Z / (1.0 / Y) => (Y * Z); NFCSanjay Patel2020-01-091-2/+2
| | | | | | Patch by: @raghesh (Raghesh Aloor) Differential Revision: https://reviews.llvm.org/D72431
* [InstCombine] Adding testcase for Z / (1.0 / Y) => (Y * Z); NFCSanjay Patel2020-01-081-0/+15
| | | | | | | | | | | | | The added testcase shows the current transformation for the operation Z / (1.0 / Y), which remains unchanged. This will be updated to align with the transformed code (Y * Z) with D72319. The existing transformation Z / (X / Y) => (Y * Z) / X is not handling this case as there are multiple uses for (1.0 / Y) in this testcase. Patch by: @raghesh (Raghesh Aloor) Differential Revision: https://reviews.llvm.org/D72388
* [InstCombine] canonicalize fneg before fmul/fdivSanjay Patel2019-07-311-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC][FPEnv] Pre-commit tests for canonicalize negated operand of fdiv.Cameron McInally2019-07-291-0/+22
| | | | llvm-svn: 367233
* [InstCombine] canonicalize negated operand of fdivSanjay Patel2019-07-261-5/+4
| | | | | | | This is a transform that we use with fmul, so use it for fdiv too for consistency. llvm-svn: 367146
* [InstCombine] add tests for fdiv with negated operand; NFCSanjay Patel2019-07-261-0/+35
| | | | llvm-svn: 367145
* [NFC][InstCombine] Add unary FNeg tests to fdiv.llCameron McInally2019-05-311-0/+118
| | | | llvm-svn: 362231
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+383
| | | | | | | | 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-383/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [PatternMatch] define m_FNeg using m_FSubSanjay Patel2018-04-051-5/+2
| | | | | | | | | Using cstfp_pred_ty in the definition allows us to match vectors with undef elements. This replicates the change for m_Not from D44076 / rL326823 and continues towards making all pattern matchers allow undef elements in vectors. llvm-svn: 329303
* [InstCombine, InstSimplify] add tests with undef elements in constant FP ↵Sanjay Patel2018-02-261-0/+33
| | | | | | vectors; NFC llvm-svn: 326148
* [InstCombine] allow fdiv folds with less than fully 'fast' opsSanjay Patel2018-02-261-8/+8
| | | | | | | | | | | | | | | | | | Note: gcc appears to allow this fold with -freciprocal-math alone, but clang/llvm require more than that with this patch. The wording in the definitions seems fuzzy enough that it could go either way, but we'll err on the conservative side of FMF interpretation. This patch also changes the newly created fmul to have FMF propagated by the last fdiv rather than intersecting the FMF of the fdivs. This matches the behavior of other folds near here. The new fmul is only used to produce an intermediate op for the final fdiv result, so it shouldn't be any stricter than that result. The previous behavior could result in dropping FMF via other folds in instcombine or CSE. Differential Revision: https://reviews.llvm.org/D43398 llvm-svn: 326098
* [InstCombine] C / -X --> -C / XSanjay Patel2018-02-211-4/+2
| | | | | | | | | We already do this in DAGCombiner, but it should also be good to eliminate the fsub use in IR. This is similar to rL325648. llvm-svn: 325649
* [InstCombine] -X / C --> X / -C for FPSanjay Patel2018-02-201-10/+8
| | | | | | | We already do this in DAGCombiner, but it should also be good to eliminate the fsub use in IR. llvm-svn: 325648
* [InstCombine] add tests for fdiv with negated op and constant op; NFCSanjay Patel2018-02-201-0/+44
| | | | llvm-svn: 325644
* [PatternMatch] allow vector matches with m_FNegSanjay Patel2018-02-201-3/+1
| | | | llvm-svn: 325642
* [InstCombine] add test for vector -X/-Y; NFCSanjay Patel2018-02-201-4/+17
| | | | | | m_FNeg doesn't match vector types. llvm-svn: 325637
* [InstCombine] fold fdiv with non-splat divisor to fmul: X/C --> X * (1/C)Sanjay Patel2018-02-201-3/+10
| | | | llvm-svn: 325590
* [InstCombine] allow fdiv with constant dividend folds with less than full ↵Sanjay Patel2018-02-191-6/+29
| | | | | | | | | | | | -ffast-math It's possible that we could allow this either 'arcp' or 'reassoc' alone, but this should be conservatively better than what we have right now. GCC allows this with only -freciprocal-math. The last test is changed to show a case that is expected to fold, but we need D43398. llvm-svn: 325533
* [InstCombine] move fdiv tests; NFCSanjay Patel2018-02-191-0/+37
| | | | | | Also, use vector constants just to prove that already works. llvm-svn: 325530
* [InstCombine] add FMF to better show current fdiv fold behavior; NFCSanjay Patel2018-02-161-4/+4
| | | | llvm-svn: 325365
* [InstCombine] test fdiv folds better; NFCSanjay Patel2018-02-151-9/+43
| | | | | | | We had redundant tests, but no tests for extra uses or vectors. 'fast' is an overly conservative requirement for these folds. llvm-svn: 325262
* [InstCombine] allow X / C -> X * (1.0/C) for vector splat FP constantsSanjay Patel2018-02-151-3/+14
| | | | llvm-svn: 325237
* [InstCombine] add tests and comments for fdiv X, C; NFCSanjay Patel2018-02-141-10/+77
| | | | llvm-svn: 325161
* [InstCombine] X / (X * Y) --> 1.0 / YSanjay Patel2018-02-121-6/+2
| | | | | | | | | This is similar to the instsimplify fold added with D42385 ( rL323716 ) ...but this can't be in instsimplify because we're creating/morphing a different instruction. llvm-svn: 324927
* [InstCombine] add tests for missing fdiv fold; NFCSanjay Patel2018-02-121-0/+42
| | | | llvm-svn: 324926
* [InstCombine] regenerate checks; NFCSanjay Patel2018-02-121-28/+44
| | | | llvm-svn: 324924
* InstCombine: fdiv -x, -y -> fdiv x, yMatt Arsenault2017-01-101-0/+18
| | | | llvm-svn: 291611
* Fix all the remaining lost-fast-math-flags bugs I've been able to find. The ↵Owen Anderson2014-01-201-0/+18
| | | | | | | | most important of these are cases in the generic logic for combining BinaryOperators. This logic hadn't been updated to handle FastMathFlags, and it took me a while to detect it because it doesn't show up in a simple search for CreateFAdd. llvm-svn: 199629
* Fix an instance where we would drop fast math flags when performing an fdiv ↵Owen Anderson2014-01-161-0/+8
| | | | | | to reciprocal multiply transformation. llvm-svn: 199425
* Update Transforms tests to use CHECK-LABEL for easier debugging. No ↵Stephen Lin2013-07-141-3/+3
| | | | | | | | | | | | | | | | | | | | | | functionality change. This update was done with the following bash script: find test/Transforms -name "*.ll" | \ while read NAME; do echo "$NAME" if ! grep -q "^; *RUN: *llc" $NAME; then TEMP=`mktemp -t temp` cp $NAME $TEMP sed -n "s/^define [^@]*@\([A-Za-z0-9_]*\)(.*$/\1/p" < $NAME | \ while read FUNC; do sed -i '' "s/;\(.*\)\([A-Za-z0-9_]*\):\( *\)@$FUNC\([( ]*\)\$/;\1\2-LABEL:\3@$FUNC(/g" $TEMP done mv $TEMP $NAME fi done llvm-svn: 186268
* Avoid turning a floating point division with a constant power of two into a ↵Benjamin Kramer2011-03-301-1/+1
| | | | | | | | | denormal multiplication. Some platforms may treat denormals as zero, on other platforms multiplication with a subnormal is slower than dividing by a normal. llvm-svn: 128555
* InstCombine: If the divisor of an fdiv has an exact inverse, turn it into an ↵Benjamin Kramer2011-03-301-0/+25
fmul. Fixes PR9587. llvm-svn: 128546
OpenPOWER on IntegriCloud