summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
* [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] Split the FP constant code out of lookThroughFPExtensions and ↵Craig Topper2018-02-281-15/+20
| | | | | | | | | | | | | | use nullptr as a sentinel Currently this code's control flow very much assumes that there are no meaningful checks after determining that it's a ConstantFP. So whenever it wants to stop it just does "return V". But V is also the variable name it uses when it wants to return a new value. So 'return V' appears multiple times with different meanings. This patch just moves all the code into a helper function and returns nullptr when it wants to stop. I've split this from D43774 while I try to figure out how to best handle the vector case there. But this change by itself at least seemed like a readability improvement. Differential Revision: https://reviews.llvm.org/D43833 llvm-svn: 326361
* [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-286-34/+29
| | | | | | | | 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] use FMF-copying functions to reduce code; NFCISanjay Patel2018-02-231-28/+12
| | | | llvm-svn: 325923
* [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
* [Transforms] Propagate new-format TBAA tags on simplification of ↵Ivan A. Kosarev2018-02-191-1/+3
| | | | | | | | | | | | | | memory-transfer intrinsics With this patch in place, when a new-format TBAA tag is available for a memory-transfer intrinsic call, we prefer propagating that new-format tag. Otherwise, we fallback to the old approach where we try to construct a proper TBAA access tag from 'tbaa.struct' metadata. Differential Revision: https://reviews.llvm.org/D41543 llvm-svn: 325488
* [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
* Remove useless comment - seems to be a copy+paste typo. NFCISimon Pilgrim2018-02-161-1/+0
| | | | llvm-svn: 325385
* [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] Don't fold select(C, Z, binop(select(C, X, Y), W)) -> ↵Craig Topper2018-02-141-2/+17
| | | | | | | | | | | | select(C, Z, binop(Y, W)) if the binop is rem or div. The select may have been preventing a division by zero or INT_MIN/-1 so removing it might not be safe. Fixes PR36362. Differential Revision: https://reviews.llvm.org/D43276 llvm-svn: 325148
* [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
* Adding a width of the GEP index to the Data Layout.Elena Demikhovsky2018-02-143-32/+37
| | | | | | | | | | | | | | | | | | Making a width of GEP Index, which is used for address calculation, to be one of the pointer properties in the Data Layout. p[address space]:size:memory_size:alignment:pref_alignment:index_size_in_bits. The index size parameter is optional, if not specified, it is equal to the pointer size. Till now, the InstCombiner normalized GEPs and extended the Index operand to the pointer width. It works fine if you can convert pointer to integer for address calculation and all registered targets do this. But some ISAs have very restricted instruction set for the pointer calculation. During discussions were desided to retrieve information for GEP index from the Data Layout. http://lists.llvm.org/pipermail/llvm-dev/2018-January/120416.html I added an interface to the Data Layout and I changed the InstCombiner and some other passes to take the Index width into account. This change does not affect any in-tree target. I added tests to cover data layouts with explicitly specified index size. Differential Revision: https://reviews.llvm.org/D42123 llvm-svn: 325102
* [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] Simplify MemTransferInst's source and dest alignments separatelyDaniel Neilson2018-02-121-15/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the InstCombine pass to cease using the deprecated MemoryIntrinsic::getAlignment() method, and instead we use the separate getSourceAlignment and getDestAlignment APIs to simplify the source and destination alignment attributes separately. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774, rL324781, rL324784, rL324955 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html Reviewers: majnemer, bollu, efriedma Reviewed By: efriedma Subscribers: efriedma, llvm-commits Differential Revision: https://reviews.llvm.org/D42871 llvm-svn: 324960
* [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
* [InstCombine] Add constant vector support for ~(C >> Y) --> ~C >> YSimon Pilgrim2018-02-101-5/+7
| | | | | | Includes adding m_NonNegative constant pattern matcher llvm-svn: 324825
* [InstCombine] Add constant vector support for X udiv C, where C >= signbitSimon Pilgrim2018-02-091-8/+6
| | | | llvm-svn: 324728
* [InstCombine] visitSRem - use m_Negative(APInt) helper. NFCI.Simon Pilgrim2018-02-081-1/+1
| | | | llvm-svn: 324636
* [InstCombine] Add m_Negative pattern matchingSimon Pilgrim2018-02-081-2/+1
| | | | | | Allows us to add non-uniform constant vector support for "X urem C -> X < C ? X : X - C, where C >= signbit." llvm-svn: 324631
* [InstCombine] Fix issue with X udiv (POW2_C1 << N) for non-splat constant ↵Simon Pilgrim2018-02-081-4/+6
| | | | | | | | vectors foldUDivShl was assuming that the input was a scalar or a splat constant llvm-svn: 324613
* [InstCombine] Fix issue with X udiv 2^C -> X >> C for non-splat constant vectorsSimon Pilgrim2018-02-081-3/+4
| | | | | | foldUDivPow2Cst was assuming that the input was a scalar or a splat constant llvm-svn: 324608
* Fix unused variable warning.Simon Pilgrim2018-02-081-1/+1
| | | | llvm-svn: 324605
OpenPOWER on IntegriCloud