summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstSimplify
Commit message (Collapse)AuthorAgeFilesLines
* [InstSimplify] add tests for vector select; NFCSanjay Patel2020-01-141-3/+20
|
* [InstSimplify] move tests for select from InstCombine; NFCSanjay Patel2020-01-131-0/+24
| | | | | | InstCombine has transforms that would enable these simplifications in an indirect way, but those transforms are unsafe and likely to be removed.
* [InstSimplify] select Cond, true, false --> CondSanjay Patel2020-01-091-6/+3
| | | | | | | | | | | | | | | This is step 1 of damage control assuming that we need to remove several over-reaching folds for select-of-booleans because they can cause miscompiles as shown in D72396. The scalar case seems obviously safe: https://rise4fun.com/Alive/jSj And I don't think there's any danger for vectors either - if the condition is poisoned, then the select must be poisoned too, so undef elements don't make any difference. Differential Revision: https://reviews.llvm.org/D72412
* [InstSimplify] add tests for select of true/false; NFCSanjay Patel2020-01-081-51/+80
|
* [ValueTracking] isKnownNonZero() should take non-null-ness assumptions into ↵Roman Lebedev2019-12-201-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | consideration (PR43267) Summary: It is pretty common to assume that something is not zero. Even optimizer itself sometimes emits such assumptions (e.g. `addAssumeNonNull()` in `PromoteMemoryToRegister.cpp`). But we currently don't deal with such assumptions :) The only way `isKnownNonZero()` handles assumptions is by calling `computeKnownBits()` which calls `computeKnownBitsFromAssume()`. But `x != 0` does not tell us anything about set bits, it only says that there are *some* set bits. So naturally, `KnownBits` does not get populated, and we fail to make use of this assumption. I propose to deal with this special case by special-casing it via adding a `isKnownNonZeroFromAssume()` that returns boolean when there is an applicable assumption. While there, we also deal with other predicates, mainly if the comparison is with constant. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=43267 | PR43267 ]]. Differential Revision: https://reviews.llvm.org/D71660
* [NFC][InstCombine] Add some more non-zero assumption variants (D71660)Roman Lebedev2019-12-191-0/+229
| | | | https://rise4fun.com/Alive/6yR
* [InstSimplify] fold splat of inserted constant to vector constantSanjay Patel2019-12-151-9/+3
| | | | | | | | | | | | | | | | | shuf (inselt ?, C, IndexC), undef, <IndexC, IndexC...> --> <C, C...> This is another missing shuffle fold pattern uncovered by the shuffle correctness fix from D70246. The problem was visible in the post-commit thread example, but we managed to overcome the limitation for that particular case with D71220. This is something like the inverse of the previous fix - there we didn't demand the inserted scalar, and here we are only demanding an inserted scalar. Differential Revision: https://reviews.llvm.org/D71488
* [InstSimplify] improve test coverage for insert+splat; NFCSanjay Patel2019-12-131-10/+21
|
* [InstSimplify] add tests for insert constant + splat; NFCSanjay Patel2019-12-101-0/+22
|
* [ValueTracking] Allow context-sensitive nullness check for non-pointersJohannes Doerfert2019-12-091-7/+50
| | | | | | | | | | | | | | | | | | Summary: Same as D60846 and D69571 but with a fix for the problem encountered after them. Both times it was a missing context adjustment in the handling of PHI nodes. The reproducers created from the bugs that caused the old commits to be reverted are included. Reviewers: nikic, nlopes, mkazantsev, spatel, dlrobertson, uabelho, hakzsam, hans Subscribers: hiraditya, bollu, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71181
* [InstSimplify] fold copysign with negated operand, part 2Sanjay Patel2019-12-081-4/+2
| | | | | | | | This is another transform suggested in PR44153: https://bugs.llvm.org/show_bug.cgi?id=44153 Unlike rG12f39e0fede9, it doesn't look like the backend matches this variant.
* [InstSimplify] fold copysign with negated operandSanjay Patel2019-12-081-6/+2
| | | | | | | | This is another transform suggested in PR44153: https://bugs.llvm.org/show_bug.cgi?id=44153 The backend for some targets already manages to get this if it converts copysign to bitwise logic.
* [InstSimplify] add tests for copysign with fneg operand; NFCSanjay Patel2019-12-061-0/+44
|
* [InstSimplify] fold copysign with same args to the argSanjay Patel2019-11-261-4/+2
| | | | | | | This is correct for any value including NaN/inf. We don't have this fold directly in the backend either, but x86 manages to get it after converting things to bitops.
* [InstSimplify] add tests for copysign; NFCSanjay Patel2019-11-261-0/+21
|
* [ValueTracking] Add a basic version of isKnownNonInfinity and use it to ↵Benjamin Kramer2019-11-191-3/+36
| | | | detect more NoNaNs
* Revert 57dd4b0 "[ValueTracking] Allow context-sensitive nullness check for ↵Hans Wennborg2019-11-131-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-pointers" This caused miscompiles of Chromium (https://crbug.com/1023818). The reduced repro is small enough to fit here: $ cat /tmp/a.c unsigned char f(unsigned char *p) { unsigned char result = 0; for (int shift = 0; shift < 1; ++shift) result |= p[0] << (shift * 8); return result; } $ bin/clang -O2 -S -o - /tmp/a.c | grep -A4 f: f: # @f .cfi_startproc # %bb.0: # %entry xorl %eax, %eax retq That's nicely optimized, but I don't think it's the right result :-) > Same as D60846 but with a fix for the problem encountered there which > was a missing context adjustment in the handling of PHI nodes. > > The test that caused D60846 to be reverted was added in e15ab8f277c7. > > Reviewers: nikic, nlopes, mkazantsev,spatel, dlrobertson, uabelho, hakzsam > > Subscribers: hiraditya, bollu, llvm-commits > > Tags: #llvm > > Differential Revision: https://reviews.llvm.org/D69571 This reverts commit 57dd4b03e4806bbb4760ab6150940150d884df20.
* Add InstCombine/InstructionSimplify support for Freeze Instructionaqjune2019-11-121-0/+20
| | | | | | | | | | | | | | | Summary: - Add llvm::SimplifyFreezeInst - Add InstCombiner::visitFreeze - Add llvm tests Reviewers: majnemer, sanjoy, reames, lebedev.ri, spatel Reviewed By: reames, lebedev.ri Subscribers: reames, lebedev.ri, filcab, regehr, trentxintong, llvm-commits Differential Revision: https://reviews.llvm.org/D29013
* [InstSimplify] use FMF to improve fcmp+select foldSanjay Patel2019-11-041-24/+8
| | | | | This is part of a series of patches needed to solve PR39535: https://bugs.llvm.org/show_bug.cgi?id=39535
* [InstSimplify] add more tests for fcmp+select; NFCSanjay Patel2019-11-041-8/+36
| | | | | | The easy code fix won't catch non-canonical mismatched constant patterns, so adding extra coverage for those in case we decide that's important (but seems unlikely).
* [InstSimplify] add more tests for fcmp+select; NFCSanjay Patel2019-11-041-0/+156
| | | | | The addition of FMF for select allows more folding for these kinds of patterns.
* [ValueTracking] Allow context-sensitive nullness check for non-pointersJohannes Doerfert2019-10-311-7/+3
| | | | | | | | | | | | | | | Same as D60846 but with a fix for the problem encountered there which was a missing context adjustment in the handling of PHI nodes. The test that caused D60846 to be reverted was added in e15ab8f277c7. Reviewers: nikic, nlopes, mkazantsev,spatel, dlrobertson, uabelho, hakzsam Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69571
* [InstSimplify] fold fma/fmuladd with a NaN or undef operandSanjay Patel2019-10-021-24/+12
| | | | | | | | | | | This is intended to be similar to the constant folding results from D67446 and earlier, but not all operands are constant in these tests, so the responsibility for folding is left to InstSimplify. Differential Revision: https://reviews.llvm.org/D67721 llvm-svn: 373455
* [InstSimplify] add tests for fma/fmuladd with undef operand; NFCSanjay Patel2019-09-271-0/+54
| | | | llvm-svn: 373109
* [InstSimplify] Handle more 'A </>/>=/<= B &&/|| (A - B) !=/== 0' patterns ↵Roman Lebedev2019-09-251-24/+8
| | | | | | | | | | | (PR43251) https://rise4fun.com/Alive/sl9s https://rise4fun.com/Alive/2plN https://bugs.llvm.org/show_bug.cgi?id=43251 llvm-svn: 372928
* [NFC][InstSimplify] More exaustive test coverage for 'A </>/>=/<= B &&/|| (A ↵Roman Lebedev2019-09-251-68/+245
| | | | | | - B) !=/== 0' pattern (PR43251) llvm-svn: 372927
* [InstSimplify] simplifyUnsignedRangeCheck(): X >= Y && Y == 0 --> Y == 0Roman Lebedev2019-09-211-3/+1
| | | | | | https://rise4fun.com/Alive/v9Y4 llvm-svn: 372491
* [NFC][InstSimplify] Add exhaustive test coverage for ↵Roman Lebedev2019-09-211-0/+132
| | | | | | | | simplifyUnsignedRangeCheck(). One case is not handled. llvm-svn: 372489
* [InstSimplify] add tests for fma/fmuladd; NFCSanjay Patel2019-09-181-0/+136
| | | | llvm-svn: 372236
* [InstSimplify] simplifyUnsignedRangeCheck(): handle few tautological cases ↵Roman Lebedev2019-09-141-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | (PR43251) Summary: This is split off from D67356, since these cases produce a constant, no real need to keep them in instcombine. Alive proofs: https://rise4fun.com/Alive/u7Fk https://rise4fun.com/Alive/4lV https://bugs.llvm.org/show_bug.cgi?id=43251 Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67498 llvm-svn: 371921
* [NFC][InstSimplify] Add some more tests for D67498/D67502Roman Lebedev2019-09-132-0/+68
| | | | llvm-svn: 371877
* [InstCombine][InstSimplify] Move constant-folding tests in ↵Roman Lebedev2019-09-121-0/+140
| | | | | | result-of-usub-is-non-zero-and-no-overflow.ll llvm-svn: 371737
* [NFC][InstCombine][InstSimplify] Add test for "add-of-negative is non-zero ↵Roman Lebedev2019-09-121-0/+101
| | | | | | | | | | | and no overflow" (PR43259) https://rise4fun.com/Alive/ska https://rise4fun.com/Alive/9iX https://bugs.llvm.org/show_bug.cgi?id=43259 llvm-svn: 371736
* [InstSimplify] simplifyUnsignedRangeCheck(): handle more cases (PR43251)Roman Lebedev2019-09-121-12/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I don't have a direct motivational case for this, but it would be good to have this for completeness/symmetry. This pattern is basically the motivational pattern from https://bugs.llvm.org/show_bug.cgi?id=43251 but with different predicate that requires that the offset is non-zero. The completeness bit comes from the fact that a similar pattern (offset != zero) will be needed for https://bugs.llvm.org/show_bug.cgi?id=43259, so it'd seem to be good to not overlook very similar patterns.. Proofs: https://rise4fun.com/Alive/21b Also, there is something odd with `isKnownNonZero()`, if the non-zero knowledge was specified as an assumption, it didn't pick it up (PR43267) Reviewers: spatel, nikic, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67411 llvm-svn: 371718
* [InstSimplify] Pass SimplifyQuery into simplifyUnsignedRangeCheck() and use ↵Roman Lebedev2019-09-111-3/+1
| | | | | | | | | | it for isKnownNonZero() This was actually the original intention in D67332, but i messed up and forgot about it. This patch was originally part of D67411, but precommitting this. llvm-svn: 371630
* [NFC][InstSimplify] Add extra test for D67411 with @llvm.assumeRoman Lebedev2019-09-111-0/+21
| | | | llvm-svn: 371629
* [ConstProp] move test file from InstSimplify; NFCSanjay Patel2019-09-111-126/+0
| | | | | | | These are constant folding tests; there is no code directly in InstSimplify for this. llvm-svn: 371619
* [InstSimplify] regenerate test CHECKs; NFCSanjay Patel2019-09-111-36/+43
| | | | llvm-svn: 371617
* [NFC][InstSimplify] rewrite test added in r371537 to use non-null pointer ↵Roman Lebedev2019-09-101-43/+53
| | | | | | | | | | instead I only want to ensure that %offset is non-zero there, it doesn't matter how that info is conveyed. As filed in PR43267, the assumption way does not work. llvm-svn: 371546
* [NFC][InstCombine][InstSimplify] PR43251 - and some patterns with offset != 0Roman Lebedev2019-09-101-0/+84
| | | | | | https://rise4fun.com/Alive/21b llvm-svn: 371537
* [InstSimplify] simplifyUnsignedRangeCheck(): if we know that X != 0, handle ↵Roman Lebedev2019-09-081-49/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | more cases (PR43246) Summary: This is motivated by D67122 sanitizer check enhancement. That patch seemingly worsens `-fsanitize=pointer-overflow` overhead from 25% to 50%, which strongly implies missing folds. In this particular case, given ``` char* test(char& base, unsigned long offset) { return &base + offset; } ``` it will end up producing something like https://godbolt.org/z/LK5-iH which after optimizations reduces down to roughly ``` define i1 @t0(i8* nonnull %base, i64 %offset) { %base_int = ptrtoint i8* %base to i64 %adjusted = add i64 %base_int, %offset %non_null_after_adjustment = icmp ne i64 %adjusted, 0 %no_overflow_during_adjustment = icmp uge i64 %adjusted, %base_int %res = and i1 %non_null_after_adjustment, %no_overflow_during_adjustment ret i1 %res } ``` Without D67122 there was no `%non_null_after_adjustment`, and in this particular case we can get rid of the overhead: Here we add some offset to a non-null pointer, and check that the result does not overflow and is not a null pointer. But since the base pointer is already non-null, and we check for overflow, that overflow check will already catch the null pointer, so the separate null check is redundant and can be dropped. Alive proofs: https://rise4fun.com/Alive/WRzq There are more patterns of "unsigned-add-with-overflow", they are not handled here, but this is the main pattern, that we currently consider canonical, so it makes sense to handle it. https://bugs.llvm.org/show_bug.cgi?id=43246 Reviewers: spatel, nikic, vsk Reviewed By: spatel Subscribers: hiraditya, llvm-commits, reames Tags: #llvm Differential Revision: https://reviews.llvm.org/D67332 llvm-svn: 371349
* [NFC][InstSimplify] Some tests for dropping null check after ↵Roman Lebedev2019-09-081-0/+278
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | uadd.with.overflow of non-null (PR43246) https://rise4fun.com/Alive/WRzq Name: C <= Y && Y != 0 --> C <= Y iff C != 0 Pre: C != 0 %y_is_nonnull = icmp ne i64 %y, 0 %no_overflow = icmp ule i64 C, %y %r = and i1 %y_is_nonnull, %no_overflow => %r = %no_overflow Name: C <= Y || Y != 0 --> Y != 0 iff C != 0 Pre: C != 0 %y_is_nonnull = icmp ne i64 %y, 0 %no_overflow = icmp ule i64 C, %y %r = or i1 %y_is_nonnull, %no_overflow => %r = %y_is_nonnull Name: C > Y || Y == 0 --> C > Y iff C != 0 Pre: C != 0 %y_is_null = icmp eq i64 %y, 0 %overflow = icmp ugt i64 C, %y %r = or i1 %y_is_null, %overflow => %r = %overflow Name: C > Y && Y == 0 --> Y == 0 iff C != 0 Pre: C != 0 %y_is_null = icmp eq i64 %y, 0 %overflow = icmp ugt i64 C, %y %r = and i1 %y_is_null, %overflow => %r = %y_is_null https://bugs.llvm.org/show_bug.cgi?id=43246 llvm-svn: 371339
* [InstSimplify] guard against unreachable code (PR43218)Sanjay Patel2019-09-041-0/+23
| | | | | | | This would crash: https://bugs.llvm.org/show_bug.cgi?id=43218 llvm-svn: 370911
* [InstSimplify] Drop leftover "division-by-zero guard" around ↵Roman Lebedev2019-08-292-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `@llvm.umul.with.overflow` inverted overflow bit Summary: Now that with D65143/D65144 we've produce `@llvm.umul.with.overflow`, and with D65147 we've flattened the CFG, we now can see that the guard may have been there to prevent division by zero is redundant. We can simply drop it: ``` ---------------------------------------- Name: no overflow or zero %iszero = icmp eq i4 %y, 0 %umul = smul_overflow i4 %x, %y %umul.ov = extractvalue {i4, i1} %umul, 1 %umul.ov.not = xor %umul.ov, -1 %retval.0 = or i1 %iszero, %umul.ov.not ret i1 %retval.0 => %iszero = icmp eq i4 %y, 0 %umul = smul_overflow i4 %x, %y %umul.ov = extractvalue {i4, i1} %umul, 1 %umul.ov.not = xor %umul.ov, -1 %retval.0 = or i1 %iszero, %umul.ov.not ret i1 %umul.ov.not Done: 1 Optimization is correct! ``` Note that this is inverted from what we have in a previous patch, here we are looking for the inverted overflow bit. And that inversion is kinda problematic - given this particular pattern we neither hoist that `not` closer to `ret` (then the pattern would have been identical to the one without inversion, and would have been handled by the previous patch), neither do the opposite transform. But regardless, we should handle this too. I've filled [[ https://bugs.llvm.org/show_bug.cgi?id=42720 | PR42720 ]]. Reviewers: nikic, spatel, xbolva00, RKSimon Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65151 llvm-svn: 370351
* [InstSimplify] Drop leftover "division-by-zero guard" around ↵Roman Lebedev2019-08-292-16/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `@llvm.umul.with.overflow` overflow bit Summary: Now that with D65143/D65144 we've produce `@llvm.umul.with.overflow`, and with D65147 we've flattened the CFG, we now can see that the guard may have been there to prevent division by zero is redundant. We can simply drop it: ``` ---------------------------------------- Name: no overflow and not zero %iszero = icmp ne i4 %y, 0 %umul = umul_overflow i4 %x, %y %umul.ov = extractvalue {i4, i1} %umul, 1 %retval.0 = and i1 %iszero, %umul.ov ret i1 %retval.0 => %iszero = icmp ne i4 %y, 0 %umul = umul_overflow i4 %x, %y %umul.ov = extractvalue {i4, i1} %umul, 1 %retval.0 = and i1 %iszero, %umul.ov ret %umul.ov Done: 1 Optimization is correct! ``` Reviewers: nikic, spatel, xbolva00 Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65150 llvm-svn: 370350
* [InstSimplify] Report "Changed" also when only deleting dead instructionsBjorn Pettersson2019-08-091-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Make sure that we report that changes has been made by InstSimplify also in situations when only trivially dead instructions has been removed. If for example a call is removed the call graph must be updated. Bug seem to have been introduced by llvm-svn r367173 (commit 02b9e45a7e4b81), since the code in question was rewritten in that commit. Reviewers: spatel, chandlerc, foad Reviewed By: spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65973 llvm-svn: 368401
* [ValueTracking] When calculating known bits for integer abs, make sure we're ↵Craig Topper2019-08-071-1/+6
| | | | | | | | | | | | | | | looking at a negate and not just any instruction with the nsw flag set. The matchSelectPattern code can match patterns like (x >= 0) ? x : -x for absolute value. But it can also match ((x-y) >= 0) ? (x-y) : (y-x). If the latter form was matched we can only use the nsw flag if its set on both subtracts. This match makes sure we're looking at the former case only. Differential Revision: https://reviews.llvm.org/D65692 llvm-svn: 368195
* [InstSimplify] Add test case to show bad sign bit handling for integer abs ↵Craig Topper2019-08-031-0/+12
| | | | | | | | | | | | | | idiom in computeKnownBits. computeKnownBits will indicate the sign bit of abs is 0 if the the RHS operand returned by matchSelectPattern has the nsw flag set. For abs idioms like (X >= 0) ? X : -X, the RHS returns -X. But we can also match ((X-Y) >= 0 ? X-Y : Y-X as abs. In this case RHS will be the Y-X operand. According to Alive, the sign bit for this is only 0 if both the X-Y and Y-X operands have the nsw flag. But we're only checking the Y-X operand. llvm-svn: 367747
* [InstSimplify] remove quadratic time looping (PR42771)Sanjay Patel2019-07-271-4/+4
| | | | | | | | | | | | | | | | | | | | The test case from: https://bugs.llvm.org/show_bug.cgi?id=42771 ...shows a ~30x slowdown caused by the awkward loop iteration (rL207302) that is seemingly done just to avoid invalidating the instruction iterator. We can instead delay instruction deletion until we reach the end of the block (or we could delay until we reach the end of all blocks). There's a test diff here for a degenerate case with llvm.assume that is not meaningful in itself, but serves to verify this change in logic. This change probably doesn't result in much overall compile-time improvement because we call '-instsimplify' as a standalone pass only once in the standard -O2 opt pipeline currently. Differential Revision: https://reviews.llvm.org/D65336 llvm-svn: 367173
* [InstSimplify][NFC] Tests for skipping 'div-by-0' checks before inverted ↵Roman Lebedev2019-07-232-0/+212
| | | | | | | | | | @llvm.umul.with.overflow It would be already handled by the non-inverted case if we were hoisting the `not` in InstCombine, but we don't (granted, we don't sink it in this case either), so this is a separate case. llvm-svn: 366801
OpenPOWER on IntegriCloud