summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine
Commit message (Collapse)AuthorAgeFilesLines
* [InstCombine] fix icmp with not op and constant to work with splat vector ↵Sanjay Patel2017-06-021-2/+1
| | | | | | constant llvm-svn: 304562
* [InstCombine] fix/add tests for icmp with not ops; NFCSanjay Patel2017-06-021-10/+40
| | | | | | | The existing test was not minimal, and there was no coverage for the variants with a constant or vector types. llvm-svn: 304555
* [InstCombine] Add test cases to show missed opportunities to remove compare ↵Craig Topper2017-05-302-0/+44
| | | | | | instructions after cttz/ctlz/ctpop where some bits of the input is known. llvm-svn: 304224
* [InstCombine] Teach isAllocSiteRemovable to look through addrspacecastsArtur Pilipenko2017-05-251-2/+5
| | | | | | | | Reviewed By: reames Differential Revision: https://reviews.llvm.org/D28565 llvm-svn: 303870
* [InstCombine] make icmp-mul fold more efficientSanjay Patel2017-05-251-1/+1
| | | | | | | | | | | There's probably a lot more like this (see also comments in D33338 about responsibility), but I suspect we don't usually get a visible manifestation. Given the recent interest in improving InstCombine efficiency, another potential micro-opt that could be repeated several times in this function: morph the existing icmp pred/operands instead of creating a new instruction. llvm-svn: 303860
* [InstCombine] use m_APInt to allow icmp-mul-mul vector foldSanjay Patel2017-05-241-6/+4
| | | | | | | | | The swapped operands in the first test is a manifestation of an inefficiency for vectors that doesn't exist for scalars because the IRBuilder checks for an all-ones mask for scalars, but not vectors. llvm-svn: 303818
* [InstCombine] add tests for icmp eq (mul X, C), (mul Y, C); NFCSanjay Patel2017-05-241-0/+43
| | | | llvm-svn: 303816
* [InstCombine] move tests and use FileCheck; NFCSanjay Patel2017-05-242-19/+23
| | | | llvm-svn: 303808
* [InstCombine] add tests to show potential missing folds; NFCSanjay Patel2017-05-241-0/+39
| | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=33138 and the comments, there are multiple ways to view this. If we choose not to solve this in InstCombine, these tests will serve as documentation of that choice. llvm-svn: 303755
* [InstCombine] add tests to document bitcast + bitwise-logic behavior; NFCSanjay Patel2017-05-241-0/+45
| | | | | | | | The solution for PR26702 ( https://bugs.llvm.org/show_bug.cgi?id=26702 ) added a canonicalization rule, but the minimal regression tests don't demonstrate how that rule interacts with other folds. llvm-svn: 303750
* [InstCombine] auto-generate test checks; NFCSanjay Patel2017-05-231-19/+18
| | | | llvm-svn: 303663
* [InstCombine] allow icmp-xor folds for vectors (PR33138)Sanjay Patel2017-05-231-12/+4
| | | | | | | | | This fixes the first part of: https://bugs.llvm.org/show_bug.cgi?id=33138 More work is needed for the bitcasted variant. llvm-svn: 303660
* [InstCombine] Use update_test_checks to regenerate the ctpop test. NFCCraig Topper2017-05-231-9/+18
| | | | llvm-svn: 303659
* [InstCombine] add icmp-xor tests to show vector neglect; NFCSanjay Patel2017-05-232-87/+197
| | | | | | | | | | Also, rename the tests and the file, add comments, and add more tests because there are no existing tests for some of these folds. These patterns are particularly important for crippled vector ISAs that have limited compare predicates (PR33138). llvm-svn: 303652
* [InstCombine] Take in account the size in sext->lshr->trunc patterns.Davide Italiano2017-05-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we end up miscompiling, transforming: define i8 @tinky() { %sext = sext i1 1 to i16 %hibit = lshr i16 %sext, 15 %tr = trunc i16 %hibit to i8 ret i8 %tr } into: %sext = sext i1 1 to i8 ret i8 %sext and the first get folded to ret i8 1, while the second gets folded to ret i8 -1. Eventually we should get rid of this transform entirely, but for now, this at least fixes a know correctness bug. Differential Revision: https://reviews.llvm.org/D33338 llvm-svn: 303513
* [InstCombine] add tests for potential (lshr(sext X), C) folds; NFCSanjay Patel2017-05-211-0/+72
| | | | | | | | | As discussed in: https://reviews.llvm.org/D33338 ...we may be able to remove a wider pattern match by doing these more basic canonicalizations. llvm-svn: 303504
* SimplifyLibCalls: Optimize wcslenMatthias Braun2017-05-194-0/+415
| | | | | | | | | | | | | | | | | | | | | | | | | | Refactor the strlen optimization code to work for both strlen and wcslen. This especially helps with programs in the wild where people pass L"string"s to const std::wstring& function parameters and the wstring constructor gets inlined. This also fixes a lingerind API problem/bug in getConstantStringInfo() where zeroinitializers would always give you an empty string (without a length) back regardless of the actual length of the initializer which did not work well in the TrimAtNul==false causing the PR mentioned below. Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG memcpy lowering and may lead to some cases for out-of-bounds zeroinitializer accesses not getting optimized anymore. So some code with UB may produce out of bound memory reads now instead of just producing zeros. The refactoring "accidentally" fixes http://llvm.org/PR32124 Differential Revision: https://reviews.llvm.org/D32839 llvm-svn: 303461
* [InstCombine] *Actually* commit the test showing the miscompile.Davide Italiano2017-05-191-1/+13
| | | | | | Clarify a comment while I'm here. llvm-svn: 303447
* [InstCombine] Add tests to demonstrate the miscompile in PR33078.Davide Italiano2017-05-191-0/+39
| | | | llvm-svn: 303445
* [InstCombine] add more tests for xor-of-icmps; NFCSanjay Patel2017-05-181-0/+30
| | | | llvm-svn: 303387
* [InstCombine] move test and use better checks; NFCSanjay Patel2017-05-182-10/+17
| | | | | | Previously, this test was checking for 'or i1', but that was actually matched by 'xor i1'. llvm-svn: 303364
* Update three tests I missed in r302979 and r302990Justin Bogner2017-05-183-0/+2
| | | | llvm-svn: 303319
* [InstCombine] add test for xor-of-icmps; NFCSanjay Patel2017-05-171-2/+15
| | | | | | This is another form of the problem discussed in D32143. llvm-svn: 303315
* [InstCombine] handle icmp i1 X, C early to avoid creating an unknown patternSanjay Patel2017-05-171-4/+2
| | | | | | | | | | | The missing optimization for xor-of-icmps still needs to be added, but by being more efficient (not generating unnecessary logic ops with constants) we avoid the bug. See discussion in post-commit comments: https://reviews.llvm.org/D32143 llvm-svn: 303312
* [InstCombine] add test for missing icmp bool fold; NFCSanjay Patel2017-05-171-10/+26
| | | | llvm-svn: 303310
* [InstCombine] add isCanonicalPredicate() helper function and use it; NFCISanjay Patel2017-05-171-13/+429
| | | | | | | | | | | | | | | | | | | | There should be a slight efficiency improvement from handling icmp/fcmp with one matcher and reducing duplicated code. The larger motivation is that there are questions about how predicate canonicalization is handled, and the refactoring should make it easier if we want to change any of that behavior. 1. As noted in the code comment, we've chosen 3 of the 16 FCMP preds as not canonical. Why those 3? It goes back to rL32751 from what I can tell, but I'm not sure if there's a justification for that rule. 2. We currently do not canonicalize integer select conditions. Should we use the same rule that applies to branches for selects? 3. We currently do canonicalize some FP select conditions, and those rules would conflict with the rule shown here. Should one or both be changed? No-functional-change-intended, but adding tests anyway because there's no coverage for most of the predicates. Differential Revision: https://reviews.llvm.org/D33247 llvm-svn: 303261
* llvm/test/Transforms/InstCombine/debuginfo-skip.ll REQUIRES +asserts.NAKAMURA Takumi2017-05-161-0/+1
| | | | llvm-svn: 303216
* [InstCombine] auto-generate better checks; NFCSanjay Patel2017-05-161-40/+55
| | | | llvm-svn: 303203
* In debug builds non-trivial amount of time is spent in InstCombine processingDmitry Mikulin2017-05-161-0/+43
| | | | | | @llvm.dbg.* calls in visitCallInst(). They can be safely ignored. llvm-svn: 303202
* [InstCombine] add motivational comment for tests; NFCSanjay Patel2017-05-161-0/+5
| | | | | | | | | | | | | | | | | | | The referenced tests are derived from: https://bugs.llvm.org/show_bug.cgi?id=32791 and: https://reviews.llvm.org/D33172 The motivation for including negative tests may not be clear, so I'm adding an explanatory comment here. In the post-commit thread for r303133: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170515/453793.html ...it was mentioned that we don't want to add redundant tests. This is a valid point. But in this case, we have a patch under review (D33172) that demonstrates that no existing regression tests are affected by a proposed code change, but these are. Therefore, I think these tests have value not visible in any existing regression tests regardless of whether they show a transform. Differential Revision: https://reviews.llvm.org/D33242 llvm-svn: 303185
* [InstCombine] add tests for PR32791; NFCSanjay Patel2017-05-151-0/+70
| | | | llvm-svn: 303133
* [InstCombine] restrict icmp fold with 2 sdiv exact operands (PR32949)Sanjay Patel2017-05-151-2/+4
| | | | | | | | | | | | | | | | This is the InstCombine counterpart to D32954. I added some comments about the code duplication in: rL302436 Alive-based verification: http://rise4fun.com/Alive/dPw This is a 2nd fix for the problem reported in: https://bugs.llvm.org/show_bug.cgi?id=32949 Differential Revision: https://reviews.llvm.org/D32970 llvm-svn: 303105
* [InstCombine] Prevent InstCombine from triggering an extra iteration if ↵Craig Topper2017-05-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | something changed in the initial Worklist creation Summary: If the Worklist build causes an IR change this change flag currently factors into the flag for running another iteration of the iteration loop. But only changes during processing should trigger another loop. This patch captures the worklist creation change flag into the outside the loop flag currently used for DbgDeclares and only sends that flag up to the caller. Rerunning the loop only depends on IC.run() now. This uses the debug output of InstCombine to determine if one or two iterations run. I couldn't think of a better way to detect it since the second spurious iteration shoudn't make any visible changes. Just wasted computation. I can do a pre-commit of the test case with the CHECK-NOT as a CHECK if this is an ok way to check this. This is a subset of D31678 as I'm still not sure how to verify the analysis behavior for that. Reviewers: davide, majnemer, spatel, chandlerc Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32453 llvm-svn: 302982
* InstCombine: Move tests that use target intrinsics into subdirectoriesJustin Bogner2017-05-1338-175/+190
| | | | | | | | Tests with target intrinsics are inherently target specific, so it doesn't actually make sense to run them if we've excluded their target. llvm-svn: 302979
* [InstCombine] remove fold that swaps xor/or with constants; NFCISanjay Patel2017-05-101-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | // (X ^ C1) | C2 --> (X | C2) ^ (C1&~C2) This canonicalization was added at: https://reviews.llvm.org/rL7264 By moving xors out/down, we can more easily combine constants. I'm adding tests that do not change with this patch, so we can verify that those kinds of transforms are still happening. This is no-functional-change-intended because there's a later fold: // (X^C)|Y -> (X|Y)^C iff Y&C == 0 ...and demanded-bits appears to guarantee that any fold that would have hit the fold we're removing here would be caught by that 2nd fold. Similar reasoning was used in: https://reviews.llvm.org/rL299384 The larger motivation for removing this code is that it could interfere with the fix for PR32706: https://bugs.llvm.org/show_bug.cgi?id=32706 Ie, we're not checking if the 'xor' is actually a 'not', so we could reverse a 'not' optimization and cause an infinite loop by altering an 'xor X, -1'. Differential Revision: https://reviews.llvm.org/D33050 llvm-svn: 302733
* [InstSimplify, InstCombine] move 'or' simplification tests; NFCSanjay Patel2017-05-101-109/+0
| | | | | | | Surprisingly, I don't think these are redundant for InstSimplify. They were just misplaced as InstCombine tests. llvm-svn: 302684
* [InstCombine] remove redundant testsSanjay Patel2017-05-101-34/+0
| | | | | | | | | | | The first test in this file is duplicated exactly in and.ll -> test33. We have commuted and vector variants there too. The second test is a composite of 2 folds. The first fold is tested independently in add.ll -> flip_and_mask (including vector variant). After that transform fires, the IR is identical to the first transform. llvm-svn: 302676
* [InstCombine] fix auto-generated FileCheck-captured variable refsSanjay Patel2017-05-103-6/+6
| | | | | | | The script at utils/update_test_checks.py has (had?) a bug when variables start with the same sequence of letters (clearly, not all of the time). llvm-svn: 302674
* [InstCombine] fix typo in test comment; NFCSanjay Patel2017-05-101-1/+1
| | | | llvm-svn: 302669
* [InstCombine] add (ashr (shl i32 X, 31), 31), 1 --> and (not X), 1Sanjay Patel2017-05-101-6/+4
| | | | | | | | | | | | | | This is another step towards favoring 'not' ops over random 'xor' in IR: https://bugs.llvm.org/show_bug.cgi?id=32706 This transformation may have occurred in longer IR sequences using computeKnownBits, but that could be much more expensive to calculate. As the scalar result shows, we do not currently favor 'not' in all cases. The 'not' created by the transform is transformed again (unnecessarily). Vectors don't have this problem because vectors are (wrongly) excluded from several other combines. llvm-svn: 302659
* [InstCombine] add tests for andn; NFCSanjay Patel2017-05-091-0/+28
| | | | llvm-svn: 302599
* [InstCombine] update test file to use FileCheck; NFCSanjay Patel2017-05-091-14/+22
| | | | llvm-svn: 302585
* [InstCombineCasts] Fix checks in sext->lshr->trunc pattern.Sanjay Patel2017-05-091-6/+6
| | | | | | | | | | | | | | | The comment says to avoid the case where zero bits are shifted into the truncated value, but the code checks that the shift is smaller than the truncated value instead of the number of bits added by the sign extension. Fixing this allows a shift by more than the value size to be introduced, which is undefined behavior, so the shift is capped at the value size minus one, which has the expected behavior of filling the value with the sign bit. Patch by Jacob Young! Differential Revision: https://reviews.llvm.org/D32285 llvm-svn: 302548
* [InstCombine] add tests from D32285 to show current problems; NFCSanjay Patel2017-05-081-0/+38
| | | | llvm-svn: 302475
* [InstCombine] add folds for not-of-shift-rightSanjay Patel2017-05-081-6/+16
| | | | | | | | | | | | | | | This is another step towards getting rid of dyn_castNotVal, so we can recommit: https://reviews.llvm.org/rL300977 As the tests show, we were missing the lshr case for constants and both ashr/lshr vector splat folds. The ashr case with constant was being performed inefficiently in 2 steps. It's also possible there was a latent bug in that case because we can't do that fold if the constant is positive: http://rise4fun.com/Alive/Bge llvm-svn: 302465
* [InstCombine] move/add tests for not(shr (not X), Y); NFCSanjay Patel2017-05-082-17/+60
| | | | llvm-svn: 302451
* [ValueTracking] Use KnownOnes to provide a better bound on known zeros for ↵Craig Topper2017-05-081-4/+25
| | | | | | | | | | ctlz/cttz intrinics This patch uses KnownOnes of the input of ctlz/cttz to bound the value that can be returned from these intrinsics. This makes these intrinsics more similar to the handling for ctpop which already uses known bits to produce a similar bound. Differential Revision: https://reviews.llvm.org/D32521 llvm-svn: 302444
* [InstCombine] add another test for PR32949; NFCSanjay Patel2017-05-081-0/+13
| | | | | | | A patch for the InstSimplify variant of this bug is up for review here: https://reviews.llvm.org/D32954 llvm-svn: 302434
* [InstSimplify] use ConstantRange to simplify or-of-icmpsSanjay Patel2017-05-073-28/+1
| | | | | | | | | | | | | We can simplify (or (icmp X, C1), (icmp X, C2)) to 'true' or one of the icmps in many cases. I had to check some of these with Alive to prove to myself it's right, but everything seems to check out. Eg, the deleted code in instcombine was completely ignoring predicates with mismatched signedness. This is a follow-up to: https://reviews.llvm.org/rL301260 https://reviews.llvm.org/D32143 llvm-svn: 302370
* Cleanup tests to not share a DISubprogram between multiple Functions.Adrian Prantl2017-05-041-20/+32
| | | | | | rdar://problem/31926379 llvm-svn: 302166
OpenPOWER on IntegriCloud