summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove @brief commands from doxygen comments, too.Adrian Prantl2018-05-011-2/+2
| | | | | | | | | | | | | | | | | This is a follow-up to r331272. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done https://reviews.llvm.org/D46290 llvm-svn: 331275
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-4/+4
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [InstCombine] allow more fmul folds with 'reassoc'Sanjay Patel2018-04-031-64/+64
| | | | | | | | 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] improve code comment; NFCSanjay Patel2018-03-261-2/+2
| | | | llvm-svn: 328560
* [InstCombine] distribute fmul over fadd/fsubSanjay Patel2018-03-261-98/+15
| | | | | | | | | | 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-1/+1
| | | | | | As the tests show, we could create extra instructions without any obvious benefit. llvm-svn: 328498
* [InstCombine] add nnan requirement for sqrt(x) * sqrt(y) -> sqrt(x*y)Sanjay Patel2018-03-181-1/+3
| | | | | | This is similar to D43765. llvm-svn: 327797
* [InstCombine] fix fmul reassociation to avoid creating an extra fdivSanjay Patel2018-03-131-6/+20
| | | | | | | | | | | | | 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] rearrange visitFMul; NFCISanjay Patel2018-03-021-73/+69
| | | | | | | Put the simplest non-FMF folds first, so it's easier to see what's left to fix/group/add with the FMF folds. llvm-svn: 326632
* [InstCombine] partly fix FMF for fmul+log2 foldSanjay Patel2018-03-021-52/+17
| | | | | | | | | | 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] allow fmul fold with less than 'fast'Sanjay Patel2018-03-021-1/+1
| | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | 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-1/+1
| | | | llvm-svn: 326502
* [InstCombine] simplify code for (X*Y) * X => (X*X) * Y ; NFCISanjay Patel2018-03-011-35/+17
| | | | llvm-svn: 326444
* [InstCombine] simplify code for X * -1.0 --> -X; NFCSanjay Patel2018-02-281-7/+3
| | | | | | I've added random FMF to one of the tests to show those are propagated. llvm-svn: 326377
* [InstCombine] move invariant call out of loop; NFCSanjay Patel2018-02-281-4/+4
| | | | | | We really shouldn't need a 2-loop here at all, but that's another cleanup. llvm-svn: 326330
* [InstCombine] move constant check into foldBinOpIntoSelectOrPhi; NFCISanjay Patel2018-02-281-17/+15
| | | | | | | | Also, rename 'foldOpWithConstantIntoOperand' because that's annoyingly vague. The constant check is redundant in some cases, but it allows removing duplication for most of the calls. llvm-svn: 326329
* [InstCombine] allow fdiv folds with less than fully 'fast' opsSanjay Patel2018-02-261-13/+3
| | | | | | | | | | | | | | | | | | 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] simplify code for fabs(X) * fabs(X) -> X * X; NFCSanjay Patel2018-02-231-13/+4
| | | | llvm-svn: 325968
* [InstSimplify] sqrt(X) * sqrt(X) --> XSanjay Patel2018-02-231-4/+0
| | | | | | This was misplaced in InstCombine. We can loosen the FMF as a follow-up step. llvm-svn: 325965
* [InstCombine] allow fmul-sqrt folds with less than full -ffast-mathSanjay Patel2018-02-231-15/+8
| | | | | | Also, add a Builder method for intrinsics to reduce code duplication for clients. llvm-svn: 325960
* [InstCombine] refactor fmul with negated op folds; NFCISanjay Patel2018-02-231-24/+18
| | | | | | | | | | | | | | The existing code was inefficiently looking for 'nsz' variants. That's unnecessary because we canonicalize those to the expected form with -0.0. We may also want to adjust or remove the fold that sinks negation. We don't do that for fdiv (or integer ops?). That should be uniform? It may also lead to missed optimization as in PR21914: https://bugs.llvm.org/show_bug.cgi?id=21914 ...or we just have to fix other passes to avoid that problem. llvm-svn: 325924
* [InstCombine] add and use Create*FMF functions; NFCSanjay Patel2018-02-211-15/+7
| | | | llvm-svn: 325730
* [InstCombine] C / -X --> -C / XSanjay Patel2018-02-211-8/+17
| | | | | | | | | 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-5/+12
| | | | | | | We already do this in DAGCombiner, but it should also be good to eliminate the fsub use in IR. llvm-svn: 325648
* [InstCombine] remove unneeded operand swap: NFCISanjay Patel2018-02-201-3/+0
| | | | | | | FMul is commutative, so complexity-based canonicalization should always take care of the swap via SimplifyAssociativeOrCommutative(). llvm-svn: 325628
* [InstCombine] remove unneeded dyn_cast to prevent unused variable warningSanjay Patel2018-02-201-2/+1
| | | | llvm-svn: 325597
* [InstCombine] remove compound fdiv pattern foldsSanjay Patel2018-02-201-27/+1
| | | | | | | | | | | | | | These are fdiv-with-constant-divisor, so they already become reciprocal multiplies. The last gap for vector ops should be closed with rL325590. It's possible that we're missing folds for some edge cases with denormal intermediate constants after deleting these, but there are no tests for those patterns, and it would be better to handle denormals more consistently (and less conservatively) as noted in TODO comments. llvm-svn: 325595
* [InstCombine] fold fdiv with non-splat divisor to fmul: X/C --> X * (1/C)Sanjay Patel2018-02-201-21/+16
| | | | llvm-svn: 325590
* [InstCombine] use CreateWithCopiedFlags to reduce code; NFCISanjay Patel2018-02-191-7/+6
| | | | | | Also, move the folds with constants closer to make it easier to follow. llvm-svn: 325541
* [InstCombine] allow fdiv with constant dividend folds with less than full ↵Sanjay Patel2018-02-191-2/+3
| | | | | | | | | | | | -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] refactor fdiv with constant dividend folds; NFCSanjay Patel2018-02-191-26/+27
| | | | | | | | | The last fold that used to be here was not necessary. That's a combination of 2 folds (and there's a regression test to show that). The transforms are guarded by isFast(), but that should be loosened. llvm-svn: 325531
* [Constant] add floating-point helpers for normal/finite-nz; NFCSanjay Patel2018-02-161-42/+13
| | | | | | | | | ...and delete the equivalent local functiona from InstCombine. These might be useful to other InstCombine files or other passes and makes FP queries more similar to integer constant queries. llvm-svn: 325398
* [InstCombine] clean up fdiv-with-fdiv folds; NFCISanjay Patel2018-02-161-28/+23
| | | | llvm-svn: 325366
* [InstCombine] remove redundant debug info setting; NFCSanjay Patel2018-02-161-2/+0
| | | | | | The IRBuilder sets debuginfo in Insert(), so this was duplicating what already happened. llvm-svn: 325358
* [InstCombine] reduce code duplication; NFCSanjay Patel2018-02-161-31/+19
| | | | llvm-svn: 325353
* [InstCombine] use m_OneUse to reduce code; NFCSanjay Patel2018-02-151-2/+2
| | | | llvm-svn: 325263
* [InstCombine] allow sin/cos transforms with 'reassoc'Sanjay Patel2018-02-151-2/+1
| | | | | | | | | | | | | | | | The variable name 'AllowReassociate' is a lie at this point because it's set to 'isFast()' which is more than the 'reassoc' FMF after rL317488. In D41286, we showed that this transform may be valid even with strict math by brute force checking every 32-bit float result. There's a potential problem here because we're replacing with a tan() libcall rather than a hypothetical LLVM tan intrinsic. So we might set errno when we should be guaranteed not to do that. But that's independent of this change. llvm-svn: 325247
* [InstCombine] allow X / C -> X * (1.0/C) for vector splat FP constantsSanjay Patel2018-02-151-11/+9
| | | | llvm-svn: 325237
* [InstCombine] clean up fold for X / C -> X * (1.0/C); NFCISanjay Patel2018-02-141-34/+27
| | | | | | This should work with vector constants too, but it's currently limited to scalar. llvm-svn: 325187
* [InstCombine] simplify isFMulOrFDivWithConstant(); NFCISanjay Patel2018-02-141-15/+7
| | | | llvm-svn: 325142
* [InstCombine] replace isa/cast with dyn_cast; NFCSanjay Patel2018-02-141-3/+2
| | | | llvm-svn: 325141
* [InstCombine] refactor folds for mul with negated operands; NFCISanjay Patel2018-02-141-10/+14
| | | | | | | This keeps with our current usage of 'match' and is easier to see that the optional NSW only applies in the non-constant operand case. llvm-svn: 325140
* [InstCombine] (lshr X, 31) * Y --> (ashr X, 31) & YSanjay Patel2018-02-131-25/+13
| | | | | | | | | | | This replaces the bit-tracking based fold that did the same thing, but it only worked for scalars and not directly. There is no evidence in existing regression tests that the greater power of bit-tracking was needed here, but we should be aware of this potential loss of optimization. llvm-svn: 325062
* [InstCombine] (bool X) * Y --> X ? Y : 0Sanjay Patel2018-02-131-0/+9
| | | | | | | | | This is both a functional improvement for vectors and an efficiency improvement for scalars. The existing code below the new folds does the same thing for scalars, but in an indirect and expensive way. llvm-svn: 325048
* [InstCombine] Simplify getLogBase2 case for scalar/splats. NFCI.Simon Pilgrim2018-02-131-3/+2
| | | | llvm-svn: 325003
* [InstCombine] X / (X * Y) --> 1.0 / YSanjay Patel2018-02-121-0/+10
| | | | | | | | | 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] various clean-ups for div transforms; NFCSanjay Patel2018-02-121-108/+94
| | | | llvm-svn: 324922
* [InstCombine] various clean-ups for commonIDivTransforms; NFCSanjay Patel2018-02-121-16/+17
| | | | llvm-svn: 324891
* [InstCombine] X / (X * Y) -> 1 / Y if the multiplication does not overflowSanjay Patel2018-02-111-0/+11
| | | | | | | | | | | The related cases for (X * Y) / X were handled in rL124487. https://rise4fun.com/Alive/6k9 The division in these tests is subsequently eliminated by existing instcombines for 1/X. llvm-svn: 324843
OpenPOWER on IntegriCloud