summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/fmul.ll
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] Simplify binary op when only one operand is a selectJay Foad2019-11-111-6/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: SimplifySelectsFeedingBinaryOp simplified binary ops when both operands were selects with the same condition. This patch extends it to handle these cases where only one operand is a select: X op (C ? P : Q) -> C ? (X op P) : (X op Q) // if X op P and X op Q both simplify (C ? P : Q) op Y -> C ? (P op Y) : (Q op Y) // if P op Y and Q op Y both simplify For example: X *fast (C ? 1.0 : 0.0) -> C ? X : 0.0 Reviewers: mcberg2017, majnemer, craig.topper, qcolombet, mcrosier Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64713
* Pre-commit test cases for D64713.Jay Foad2019-10-211-0/+50
| | | | llvm-svn: 375418
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-141-4/+4
| | | | | | | | Reapply r374240 with fix for Ocaml test, namely Bindings/OCaml/core.ml. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374782
* Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko2019-10-101-4/+4
| | | | | | | This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-091-4/+4
| | | | | | | | Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374240
* [InstCombine] fold fneg disguised as select+fmul (PR43497)Sanjay Patel2019-10-061-12/+16
| | | | | | | Extends rL373230 and solves the motivating bug (although in a narrow way): https://bugs.llvm.org/show_bug.cgi?id=43497 llvm-svn: 373851
* [InstCombine] add fast-math-flags for better test coverage; NFCSanjay Patel2019-10-061-4/+4
| | | | llvm-svn: 373848
* [InstCombine] add tests for fneg disguised as fmul; NFCSanjay Patel2019-10-041-0/+74
| | | | llvm-svn: 373788
* [InstCombine] canonicalize fneg before fmul/fdivSanjay Patel2019-07-311-29/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] don't move FP negation out of a constant expressionSanjay Patel2019-07-111-0/+13
| | | | | | | -(X * ConstExpr) becomes X * (-ConstExpr), so don't reverse that and infinite loop. llvm-svn: 365774
* [NFC][InstCombine] Add unary FNeg tests to fmul.llCameron McInally2019-05-301-0/+205
| | | | llvm-svn: 362137
* Revert "Temporarily Revert "Add basic loop fusion pass.""Eric Christopher2019-04-171-0/+778
| | | | | | | | 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-778/+0
| | | | | | | | As it's causing some bot failures (and per request from kbarton). This reverts commit r358543/ab70da07286e618016e78247e4a24fcb84077fda. llvm-svn: 358546
* [InstCombine] canonicalize fdiv after fmul if reassociation is allowedSanjay Patel2019-04-151-18/+18
| | | | | | | | (X / Y) * Z --> (X * Z) / Y This can allow other optimizations/reassociations as shown in the test diffs. llvm-svn: 358404
* [InstCombine] add tests for fdiv+fmul; NFCSanjay Patel2019-04-051-0/+82
| | | | llvm-svn: 357782
* [InstCombine] add test to show reassociation that creates a denormal ↵Sanjay Patel2019-04-051-0/+15
| | | | | | constant; NFC llvm-svn: 357776
* [PatternMatch] define m_FNeg using m_FSubSanjay Patel2018-04-051-7/+4
| | | | | | | | | 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] add vector and vector undef tests for FP folds; NFCSanjay Patel2018-04-051-12/+79
| | | | llvm-svn: 329294
* [InstCombine] allow more fmul folds with 'reassoc'Sanjay Patel2018-04-031-25/+28
| | | | | | | | The tests marked with 'FIXME' require loosening the check in SimplifyAssociativeOrCommutative() to optimize completely; that's still checking isFast() in Instruction::isAssociative(). llvm-svn: 329121
* [InstCombine] distribute fmul over fadd/fsubSanjay Patel2018-03-261-9/+6
| | | | | | | | | | This replaces a large chunk of code that was looking for compound patterns that include these sub-patterns. Existing tests ensure that all of the previous examples are still folded as expected. We still need to loosen the FMF check. llvm-svn: 328502
* [InstCombine] check uses before creating instructions for fmul distributionSanjay Patel2018-03-261-12/+3
| | | | | | As the tests show, we could create extra instructions without any obvious benefit. llvm-svn: 328498
* [InstCombine] move/add tests for fmul distribution; NFCSanjay Patel2018-03-211-0/+185
| | | | | | | | | There are at least 3 problems: 1. We're distributing across large patterns, but fail to do that for the minimal patterns. 2. We're not checking uses, so we may create more instructions than we eliminate. 3. We should be able to do these transforms with less than full 'fast' fmuls. llvm-svn: 328152
* [InstCombine] fix fmul reassociation to avoid creating an extra fdivSanjay Patel2018-03-131-13/+13
| | | | | | | | | | | | | This was supposed to be an NFC refactoring that will eventually allow eliminating the isFast() predicate, but there's a rare possibility that we would pessimize the code as shown in the test case because we failed to check 'hasOneUse()' properly. This version also removes an inefficiency of the old code; we would look for: (X * C) * C1 --> X * (C * C1) ...but that pattern is always handled by SimplifyAssociativeOrCommutative(). llvm-svn: 327404
* [InstCombine] add test to show fmul transform creates extra fdiv; NFCSanjay Patel2018-03-121-0/+107
| | | | | | Also, move fmul reassociation tests to the same file as other fmul transforms. llvm-svn: 327342
* [InstCombine] partly fix FMF for fmul+log2 foldSanjay Patel2018-03-021-6/+6
| | | | | | | | | | The code was checking that all of the instructions in the sequence are 'fast', but that's not necessary. The final multiply is all that we need to check (tests adjusted). The fmul doesn't need to be fully 'fast' either, but that can be another patch. llvm-svn: 326608
* [InstCombine] add tests for rL169025; NFCSanjay Patel2018-03-021-0/+32
| | | | | | | | This narrow fold was added with no motivation or test cases a bit over 5 years ago. Removing a constant operand is a good canonicalization? We should handle Y*2.0 too then? llvm-svn: 326606
* [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-021-9/+11
| | | | | | | | | | | | | | | | | | This is a retry of r326502 with updates to the reassociate test file that I missed the first time. @test15_reassoc in the supposed -reassociate test file (except that it tests 2 other passes too...) shows that there's no clear responsiblity for reassociation transforms. Instcombine now gets that case, but only because the constant values are identical. Otherwise, it would still miss that pattern. Reassociate doesn't get that case because it hasn't been updated to use less than 'fast' FMF. llvm-svn: 326513
* revert r326502: [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-011-13/+11
| | | | | | | | I forgot that I added tests for 'reassoc' to -reassociate, but suprisingly that file calls -instcombine too, so it is affected. I'll update that file and try again. llvm-svn: 326510
* [InstCombine] allow fmul fold with less than 'fast'Sanjay Patel2018-03-011-11/+13
| | | | llvm-svn: 326502
* [InstCombine] move/add tests for fmul reassociation; NFCSanjay Patel2018-03-011-0/+72
| | | | | | | This transform may be out-of-scope for instcombine, but this is only documenting the current behavior. llvm-svn: 326442
* [InstCombine] simplify code for X * -1.0 --> -X; NFCSanjay Patel2018-02-281-2/+2
| | | | | | I've added random FMF to one of the tests to show those are propagated. llvm-svn: 326377
* [InstSimplify] sqrt(X) * sqrt(X) --> XSanjay Patel2018-02-231-11/+0
| | | | | | This was misplaced in InstCombine. We can loosen the FMF as a follow-up step. llvm-svn: 325965
* [InstCombine] add fmul multi-use test; NFCSanjay Patel2018-02-221-14/+33
| | | | | | Also, rename tests to make their intent clearer. llvm-svn: 325785
* [InstCombine] add some random FMF to tests so we know it's not dropped; NFCSanjay Patel2018-02-211-8/+8
| | | | llvm-svn: 325734
* [InstCombine] Regenerate FMUL/FMA combine tests with update_test_checks.pySimon Pilgrim2017-12-161-45/+82
| | | | llvm-svn: 320922
* InstCombine: fabs(x) * fabs(x) -> x * xMatt Arsenault2016-01-301-0/+29
| | | | llvm-svn: 259295
* [opaque pointer type] Add textual IR support for explicit type parameter to ↵David Blaikie2015-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
* Remove unused function attribute params.Sanjay Patel2014-10-021-2/+2
| | | | llvm-svn: 218909
* Optimize square root squared (PR21126).Sanjay Patel2014-10-021-0/+29
| | | | | | | | | | | When unsafe-fp-math is enabled, we can turn sqrt(X) * sqrt(X) into X. This can happen in the real world when calculating x ** 3/2. This occurs in test-suite/SingleSource/Benchmarks/BenchmarkGame/n-body.c. Differential Revision: http://reviews.llvm.org/D5584 llvm-svn: 218906
* Fix all the remaining lost-fast-math-flags bugs I've been able to find. The ↵Owen Anderson2014-01-201-0/+10
| | | | | | | | 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
* InstCombine: Make the (fmul X, -1.0) -> (fsub -0.0, X) transform handle ↵Benjamin Kramer2014-01-181-0/+9
| | | | | | | | vectors too. PR18532. llvm-svn: 199553
* Fix a bug in InstCombine where we failed to preserve fast math flags when ↵Owen Anderson2014-01-161-3/+2
| | | | | | optimizing an FMUL expression. llvm-svn: 199424
* Teach InstCombine that (fmul X, -1.0) can be simplified to (fneg X), which ↵Owen Anderson2014-01-161-0/+12
| | | | | | LLVM expresses as (fsub -0.0, X). llvm-svn: 199420
* Fix a bug in InstCombine where it attempted to cast a Value* to an Instruction*Joey Gouly2013-09-301-0/+23
| | | | | | | | | when it was actually a Constant*. There are quite a few other casts to Instruction that might have the same problem, but this is the only one I have a test case for. llvm-svn: 191668
* Update Transforms tests to use CHECK-LABEL for easier debugging. No ↵Stephen Lin2013-07-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | 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
* 1. Hoist minus sign as high as possible in an attempt to revealShuxin Yang2013-01-151-0/+72
some optimization opportunities (in the enclosing supper-expressions). rule 1. (-0.0 - X ) * Y => -0.0 - (X * Y) if expression "-0.0 - X" has only one reference. rule 2. (0.0 - X ) * Y => -0.0 - (X * Y) if expression "0.0 - X" has only one reference, and the instruction is marked "noSignedZero". 2. Eliminate negation (The compiler was already able to handle these opt if the 0.0s are replaced with -0.0.) rule 3: (0.0 - X) * (0.0 - Y) => X * Y rule 4: (0.0 - X) * C => X * -C if the expr is flagged "noSignedZero". 3. Rule 5: (X*Y) * X => (X*X) * Y if X!=Y and the expression is flagged with "UnsafeAlgebra". The purpose of this transformation is two-fold: a) to form a power expression (of X). b) potentially shorten the critical path: After transformation, the latency of the instruction Y is amortized by the expression of X*X, and therefore Y is in a "less critical" position compared to what it was before the transformation. 4. Remove the InstCombine code about simplifiying "X * select". The reasons are following: a) The "select" is somewhat architecture-dependent, therefore the higher level optimizers are not able to precisely predict if the simplification really yields any performance improvement or not. b) The "select" operator is bit complicate, and tends to obscure optimization opportunities. It is btter to keep it as low as possible in expr tree, and let CodeGen to tackle the optimization. llvm-svn: 172551
OpenPOWER on IntegriCloud