summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add a emitUnaryFloatFnCall version that fetches the function name from TLIMikael Holmen2018-10-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In several places in the code we use the following pattern: if (hasUnaryFloatFn(&TLI, Ty, LibFunc_tan, LibFunc_tanf, LibFunc_tanl)) { [...] Value *Res = emitUnaryFloatFnCall(X, TLI.getName(LibFunc_tan), B, Attrs); [...] } In short, we check if there is a lib-function for a certain type, and then we _always_ fetch the name of the "double" version of the lib function and construct a call to the appropriate function, that we just checked exists, using that "double" name as a basis. This is of course a problem in cases where the target doesn't support the "double" version, but e.g. only the "float" version. In that case TLI.getName(LibFunc_tan) returns "", and emitUnaryFloatFnCall happily appends an "f" to "", and we erroneously end up with a call to a function called "f". To solve this, the above pattern is changed to if (hasUnaryFloatFn(&TLI, Ty, LibFunc_tan, LibFunc_tanf, LibFunc_tanl)) { [...] Value *Res = emitUnaryFloatFnCall(X, &TLI, LibFunc_tan, LibFunc_tanf, LibFunc_tanl, B, Attrs); [...] } I.e instead of first fetching the name of the "double" version and then letting emitUnaryFloatFnCall() add the final "f" or "l", we let emitUnaryFloatFnCall() fetch the right name from TLI. Reviewers: eli.friedman, efriedma Reviewed By: efriedma Subscribers: efriedma, bjope, llvm-commits Differential Revision: https://reviews.llvm.org/D53370 llvm-svn: 344725
* [IRBuilder] Fixup CreateIntrinsic to allow specifying Types to Mangle.Neil Henning2018-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | The IRBuilder CreateIntrinsic method wouldn't allow you to specify the types that you wanted the intrinsic to be mangled with. To fix this I've: - Added an ArrayRef<Type *> member to both CreateIntrinsic overloads. - Used that array to pass into the Intrinsic::getDeclaration call. - Added a CreateUnaryIntrinsic to replace the most common use of CreateIntrinsic where the type was auto-deduced from operand 0. - Added a bunch more unit tests to test Create*Intrinsic calls that weren't being tested (including the FMF flag that wasn't checked). This was suggested as part of the AMDGPU specific atomic optimizer review (https://reviews.llvm.org/D51969). Differential Revision: https://reviews.llvm.org/D52087 llvm-svn: 343962
* [InstCombine] name change: foldShuffledBinop -> foldVectorBinop; NFCSanjay Patel2018-10-031-8/+8
| | | | | | | This function will deal with more than shuffles with D50992, and I have another potential per-element fold that could live here. llvm-svn: 343692
* [InstCombine] refactor mul narrowing folds; NFCISanjay Patel2018-09-141-71/+2
| | | | | | | | | | | | | Similar to rL342278: The test diffs are all cosmetic due to the change in value naming, but I'm including that to show that the new code does perform these folds rather than something else in instcombine. D52075 should be able to use this code too rather than duplicating all of the logic. llvm-svn: 342292
* [InstCombine] Fix incorrect usage of getPrimitiveSizeInBits when we should ↵Craig Topper2018-09-111-2/+1
| | | | | | | | | | be using the element size for vectors For vectors, getPrimitiveSizeInBits returns the full vector width. This code should using the element size for vectors. This could be fixed by calling getScalarSizeInBits, but its even easier to just get it from the APInt we're checking. Differential Revision: https://reviews.llvm.org/D51938 llvm-svn: 341971
* [InstCombine] Support (mul (sext x), cst) --> (sext (mul x, cst')) and (mul ↵Craig Topper2018-09-111-2/+2
| | | | | | | | | | (zext x), cst) --> (zext (mul x, cst')) for vectors constants. Similar to D51236, but for mul instead of add. Differential Revision: https://reviews.llvm.org/D51900 llvm-svn: 341961
* [InstCombine] fold udiv with common factor from muls with nuwSanjay Patel2018-07-261-0/+15
| | | | | | | | | Unfortunately, sdiv isn't as simple because of UB due to overflow. This fold is mentioned in PR38239: https://bugs.llvm.org/show_bug.cgi?id=38239 llvm-svn: 338059
* [InstCombine] Corrections in comments for division transformation (NFC)Sanjay Patel2018-07-151-3/+3
| | | | | | | | | | The actual code seems to be correct, but the comments were misleading. Patch by Aaron Puchert! Differential Revision: https://reviews.llvm.org/D49276 llvm-svn: 337131
* [InstCombine] return when SimplifyAssociativeOrCommutative makes a changeSanjay Patel2018-07-131-3/+8
| | | | | | | | | | | | | This bug was created by rL335258 because we used to always call instsimplify after trying the associative folds. After that change it became possible for subsequent folds to encounter unsimplified code (and potentially assert because of it). Instead of carrying changed state through instcombine, we can just return immediately. This allows instsimplify to run, so we can continue assuming that easy folds have already occurred. llvm-svn: 336965
* [InstCombine] simplify code for urem fold; NFCISanjay Patel2018-06-261-5/+2
| | | | llvm-svn: 335623
* [InstCombine] fold urem with sext bool divisorSanjay Patel2018-06-261-2/+13
| | | | | | | | | | | | | | | | | | | | | | Similar to other patches in this series: https://reviews.llvm.org/rL335512 https://reviews.llvm.org/rL335527 https://reviews.llvm.org/rL335597 https://reviews.llvm.org/rL335616 ...this is filling a gap in analysis that is exposed by an unrelated select-of-constants transform. I didn't see a way to unify the sext cases because each div/rem opcode results in a different fold. Note that in this case, the backend might want to convert the select into math: Name: sext urem %e = sext i1 %x to i32 %r = urem i32 %y, %e => %c = icmp eq i32 %y, -1 %z = zext i1 %c to i32 %r = add i32 %z, %y llvm-svn: 335622
* [InstCombine] fold udiv with sext bool divisorSanjay Patel2018-06-261-1/+7
| | | | | | | | | | Note: I didn't add a hasOneUse() check because the existing, related fold doesn't have that check. I suspect that the improved analysis and codegen make these some of the rare canonicalization cases where we allow an increase in instructions. llvm-svn: 335597
* [InstCombine] cleanup udiv folds; NFCISanjay Patel2018-06-251-30/+20
| | | | | | | | | This removes a "UDivFoldAction" in favor of a simple constant matcher. In theory, the existing code could do more matching, but I don't see any evidence or need for it. I've left a TODO about using ValueTracking in case we see any regressions. llvm-svn: 335545
* [InstCombine] fold sdiv with sext bool divisorSanjay Patel2018-06-251-4/+7
| | | | llvm-svn: 335527
* [InstCombine] simplify binops before trying other foldsSanjay Patel2018-06-211-18/+25
| | | | | | | | | | This is outwardly NFC from what I can tell, but it should be more efficient to simplify first (despite the name, SimplifyAssociativeOrCommutative does not actually simplify as InstSimplify does - it creates/morphs instructions). This should make it easier to refactor duplicated code that runs for all binops. llvm-svn: 335258
* [InstCombine] Fix div handlingSerguei Katkov2018-06-041-2/+2
| | | | | | | | | | | | | When we optimize select basing on fact that div by 0 is undef we should not traverse the instruction which are not guaranteed to transfer execution to next instruction. Guard intrinsic is an example. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47576 llvm-svn: 333864
* [InstCombine] call simplify before trying vector foldsSanjay Patel2018-06-021-32/+24
| | | | | | | | | | | | | | | | | | | | As noted in the review thread for rL333782, we could have made a bug harder to hit if we were simplifying instructions before trying other folds. The shuffle transform in question isn't ever a simplification; it's just a canonicalization. So I've renamed that to make that clearer. This is NFCI at this point, but I've regenerated the test file to show the cosmetic value naming difference of using instcombine's RAUW vs. the builder. Possible follow-ups: 1. Move reassociation folds after simplifies too. 2. Refactor common code; we shouldn't have so much repetition. llvm-svn: 333820
* [InstCombine] Moving overflow computation logic from InstCombine to ↵Omer Paparo Bivas2018-05-101-41/+0
| | | | | | | | | ValueTracking; NFC Differential Revision: https://reviews.llvm.org/D46704 Change-Id: Ifabcbe431a2169743b3cc310f2a34fd706f13f02 llvm-svn: 332026
* 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
OpenPOWER on IntegriCloud