summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstSimplify
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstSimplify] move misplaced minnum/maxnum tests; NFCSanjay Patel2018-08-071-0/+16
| | | | llvm-svn: 339141
* ValueTracking: Handle canonicalize in CannotBeNegativeZeroMatt Arsenault2018-08-061-0/+50
| | | | | | | Also fix apparently missing test coverage for any of the handling here. llvm-svn: 339023
* [InstSimplify] fold extracting from std::pair (2/2)Hiroshi Inoue2018-08-031-34/+9
| | | | | | | | | | | This is the second patch of the series which intends to enable jump threading for an inlined method whose return type is std::pair<int, bool> or std::pair<bool, int>. The first patch is https://reviews.llvm.org/rL338485. This patch handles code sequences that merges two values using `shl` and `or`, then extracts one value using `and`. Differential Revision: https://reviews.llvm.org/D49981 llvm-svn: 338817
* [InstSimplify] move minnum/maxnum with undef fold from instcombineSanjay Patel2018-08-021-0/+32
| | | | llvm-svn: 338719
* [ValueTracking] fix maxnum miscompile for cannotBeOrderedLessThanZero (PR37776)Sanjay Patel2018-08-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the NAN checks suggested in PR37776: https://bugs.llvm.org/show_bug.cgi?id=37776 If both operands to maxnum are NAN, that should get constant folded, so we don't have to handle that case. This is the same assumption as other FP ops in this function. Returning 'false' is always conservatively correct. Copying from the bug report: Currently, we have this for "when is cannotBeOrderedLessThanZero (mustBePositiveOrNaN) true for maxnum": L ------------------- | Pos | Neg | NaN | ------------------------ |Pos | x | x | x | ------------------------ R |Neg | x | | x | ------------------------ |NaN | x | x | x | ------------------------ The cases with (Neg & NaN) are wrong. We should have: L ------------------- | Pos | Neg | NaN | ------------------------ |Pos | x | x | x | ------------------------ R |Neg | x | | | ------------------------ |NaN | x | | x | ------------------------ Differential Revision: https://reviews.llvm.org/D50081 llvm-svn: 338716
* [InstSimplify] move minnum/maxnum with same arg fold from instcombineSanjay Patel2018-08-011-2/+19
| | | | llvm-svn: 338652
* [InstSimplify] fold extracting from std::pair (1/2)Hiroshi Inoue2018-08-011-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch intends to enable jump threading when a method whose return type is std::pair<int, bool> or std::pair<bool, int> is inlined. For example, jump threading does not happen for the if statement in func. std::pair<int, bool> callee(int v) { int a = dummy(v); if (a) return std::make_pair(dummy(v), true); else return std::make_pair(v, v < 0); } int func(int v) { std::pair<int, bool> rc = callee(v); if (rc.second) { // do something } SROA executed before the method inlining replaces std::pair by i64 without splitting in both callee and func since at this point no access to the individual fields is seen to SROA. After inlining, jump threading fails to identify that the incoming value is a constant due to additional instructions (like or, and, trunc). This series of patch add patterns in InstructionSimplify to fold extraction of members of std::pair. To help jump threading, actually we need to optimize the code sequence spanning multiple BBs. These patches does not handle phi by itself, but these additional patterns help NewGVN pass, which calls instsimplify to check opportunities for simplifying instructions over phi, apply phi-of-ops optimization to result in successful jump threading. SimplifyDemandedBits in InstCombine, can do more general optimization but this patch aims to provide opportunities for other optimizers by supporting a simple but common case in InstSimplify. This first patch in the series handles code sequences that merges two values using shl and or and then extracts one value using lshr. Differential Revision: https://reviews.llvm.org/D48828 llvm-svn: 338485
* [InstSimplify] Fold another Select with And/Or patternDavid Bolvansky2018-07-312-50/+10
| | | | | | | | | | | | | | Summary: Proof: https://rise4fun.com/Alive/L5J Reviewers: lebedev.ri, spatel Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49975 llvm-svn: 338383
* [InstSimplify] tests for D48828, D49981: fold extraction from std::pairHiroshi Inoue2018-07-312-12/+12
| | | | | | Minor touch up in the previous comment. llvm-svn: 338351
* [InstSimplify] tests for D48828, D49981: fold extraction from std::pairHiroshi Inoue2018-07-312-20/+100
| | | | | | Updated unit tests for D48828 and D49981. llvm-svn: 338350
* [InstSimplify] [NFC] Tests for Select with AND/OR foldDavid Bolvansky2018-07-302-4/+361
| | | | llvm-svn: 338285
* [InstSimplify] fold funnel shifts with 0-shift amountSanjay Patel2018-07-291-12/+6
| | | | llvm-svn: 338218
* [InstSimplify] add tests for funnel shift intrinsics; NFCSanjay Patel2018-07-291-10/+66
| | | | llvm-svn: 338217
* [InstSimplify] Moved Select + AND/OR tests from InstCombineDavid Bolvansky2018-07-282-0/+361
| | | | | | | | Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49957 llvm-svn: 338195
* [InstSimplify] tests for D48828: fold extraction from std::pairHiroshi Inoue2018-07-272-0/+183
| | | | | | | This commit includes unit tests for D48828, which enhances InstSimplify to enable jump threading with a method whose return type is std::pair<int, bool> or std::pair<bool, int>. I am going to commit the actual transformation later. llvm-svn: 338107
* [InstrSimplify] fold sdiv if two operands are negated and non-overflowChen Zheng2018-07-211-24/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D49382 llvm-svn: 337642
* [NFC][testcases] fold sdiv if two operands are negated and non-overflowChen Zheng2018-07-201-0/+147
| | | | llvm-svn: 337549
* [InstSimplify] fold srem instruction if its two operands are negated.Chen Zheng2018-07-201-25/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D49423 llvm-svn: 337545
* [NFC][testcases] more testcases for folding srem if its two operands are ↵Chen Zheng2018-07-201-0/+34
| | | | | | negatived. llvm-svn: 337543
* [NFC][testcases] add testcases for folding srem whose operands are negatived.Chen Zheng2018-07-171-0/+49
| | | | | | | Finish same optimization for add instruction in D49216 and sdiv instruction in D49382. This patch is for srem instruction. llvm-svn: 337270
* [testcases] move testcases to right place - NFCChen Zheng2018-07-171-0/+49
| | | | | | Differential Revision: https://reviews.llvm.org/D49409 llvm-svn: 337230
* [InstSimplify] add fixme comment for PR37776; NFCSanjay Patel2018-07-151-0/+4
| | | | llvm-svn: 337129
* [InstSimplify] fold minnum/maxnum with NaN argSanjay Patel2018-07-151-16/+8
| | | | | | | | | | | | | | | This fold is repeated/misplaced in instcombine, but I'm not sure if it's safe to remove that yet because some other folds appear to be asserting that the transform has occurred within instcombine itself. This isn't the best fix for PR37776, but it probably hides the bug with the given code example: https://bugs.llvm.org/show_bug.cgi?id=37776 We have another test to demonstrate the more general bug. llvm-svn: 337127
* [InstSimplify] add tests for minnum/maxnum; NFCSanjay Patel2018-07-151-0/+82
| | | | | | | | | | | This isn't the best fix for PR37776, but it probably hides the bug with the given code example: https://bugs.llvm.org/show_bug.cgi?id=37776 We have another test to demonstrate the more general bug. llvm-svn: 337126
* [InstSimplify] simplify add instruction if two operands are negativeChen Zheng2018-07-121-8/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D49216 llvm-svn: 336881
* [InstSimplify] add/move tests for add folds; NFCSanjay Patel2018-07-111-0/+57
| | | | | | | | isKnownNegation() is currently proposed as part of D48754, but it could be used to make InstSimplify stronger independently of any abs() improvements. llvm-svn: 336822
* llvm: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-091-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in LLVM IR in this CL as the function attribute "null-pointer-is-valid"="true" in IR (Under review at D47894). The CL updates several passes that assumed null pointer dereferencing is undefined to not optimize when the "null-pointer-is-valid"="true" attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: efriedma, george.burgess.iv Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits Differential Revision: https://reviews.llvm.org/D47895 llvm-svn: 336613
* [InstSimplify] fold shifts by sext boolSanjay Patel2018-06-261-18/+6
| | | | | | https://rise4fun.com/Alive/c3Y llvm-svn: 335633
* [InstSimplify] add tests for shifts by sext bool; NFCSanjay Patel2018-06-261-0/+66
| | | | llvm-svn: 335631
* [InstSimplify] fold srem with sext bool divisorSanjay Patel2018-06-261-6/+2
| | | | llvm-svn: 335616
* [InstSimplify] add tests for srem with sext bool divisor; NFCSanjay Patel2018-06-261-0/+23
| | | | llvm-svn: 335609
* [InstSimplify] fold div/rem of zexted boolSanjay Patel2018-06-252-12/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was looking at an unrelated fold and noticed that we don't have this simplification (because the other fold would break existing tests). Name: zext udiv %z = zext i1 %x to i32 %r = udiv i32 %y, %z => %r = %y Name: zext urem %z = zext i1 %x to i32 %r = urem i32 %y, %z => %r = 0 Name: zext sdiv %z = zext i1 %x to i32 %r = sdiv i32 %y, %z => %r = %y Name: zext srem %z = zext i1 %x to i32 %r = srem i32 %y, %z => %r = 0 https://rise4fun.com/Alive/LZ9 llvm-svn: 335512
* [InstSimplify] add tests for div/rem with bool divisor; NFCSanjay Patel2018-06-252-0/+44
| | | | llvm-svn: 335509
* [InstSimplify] Fix missed optimization in simplifyUnsignedRangeCheck()Sanjay Patel2018-06-201-18/+6
| | | | | | | | | | | | | | | | | | | | | For both operands are unsigned, the following optimizations are valid, and missing: 1. X > Y && X != 0 --> X > Y 2. X > Y || X != 0 --> X != 0 3. X <= Y || X != 0 --> true 4. X <= Y || X == 0 --> X <= Y 5. X > Y && X == 0 --> false unsigned foo(unsigned x, unsigned y) { return x > y && x != 0; } should fold to x > y, but I found we haven't done it right now. besides, unsigned foo(unsigned x, unsigned y) { return x < y && y != 0; } Has been folded to x < y, so there may be a bug. Patch by: Li Jia He! Differential Revision: https://reviews.llvm.org/D47922 llvm-svn: 335129
* [InstSimplify] Add tests for missed optimizations in ↵Sanjay Patel2018-06-201-2/+67
| | | | | | | | | | | | simplifyUnsignedRangeCheck (NFC) These are the baseline tests for the functional change in D47922. Patch by Li Jia He! Differential Revision: https://reviews.llvm.org/D48000 llvm-svn: 335128
* [InstSimplify] add nuw %x, -1 -> -1 fold.Roman Lebedev2018-06-081-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `%ret = add nuw i8 %x, C` From [[ https://llvm.org/docs/LangRef.html#add-instruction | langref ]]: nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”, respectively. If the nuw and/or nsw keywords are present, the result value of the add is a poison value if unsigned and/or signed overflow, respectively, occurs. So if `C` is `-1`, `%x` can only be `0`, and the result is always `-1`. I'm not sure we want to use `KnownBits`/`LVI` here, because there is exactly one possible value (all bits set, `-1`), so some other pass should take care of replacing the known-all-ones with constant `-1`. The `test/Transforms/InstCombine/set-lowbits-mask-canonicalize.ll` change *is* confusing. What happening is, before this: (omitting `nuw` for simplicity) 1. First, InstCombine D47428/rL334127 folds `shl i32 1, %NBits`) to `shl nuw i32 -1, %NBits` 2. Then, InstSimplify D47883/rL334222 folds `shl nuw i32 -1, %NBits` to `-1`, 3. `-1` is inverted to `0`. But now: 1. *This* InstSimplify fold `%ret = add nuw i32 %setbit, -1` -> `-1` happens first, before InstCombine D47428/rL334127 fold could happen. Thus we now end up with the opposite constant, and it is all good: https://rise4fun.com/Alive/OA9 https://rise4fun.com/Alive/sldC Was mentioned in D47428 review. Follow-up for D47883. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47908 llvm-svn: 334298
* [NFC][InstSimplify] Add tests for add nuw %x, -1 -> -1 fold.Roman Lebedev2018-06-071-0/+145
| | | | | | | | | | | | | | | | %ret = add nuw i8 %x, C From langref: nuw and nsw stand for “No Unsigned Wrap” and “No Signed Wrap”, respectively. If the nuw and/or nsw keywords are present, the result value of the add is a poison value if unsigned and/or signed overflow, respectively, occurs. So if C is -1, %x can only be 0, and the result is always -1. https://rise4fun.com/Alive/sldC Was mentioned in D47428 review. llvm-svn: 334236
* [NFC][InstSimplify] One more negative test for shl nuw C, %x -> C fold.Roman Lebedev2018-06-071-1/+10
| | | | | | Follow-up for rL334200, rL334206. llvm-svn: 334235
* [InstSimplify] shl nuw C, %x -> C iff signbit is set on C.Roman Lebedev2018-06-071-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `%r = shl nuw i8 C, %x` As per langref: ``` If the nuw keyword is present, then the shift produces a poison value if it shifts out any non-zero bits. ``` Thus, if the sign bit is set on `C`, then `%x` can only be `0`, which means that `%r` can only be `C`. Or in other words, set sign bit means that the signed value is negative, so the constant is `<= 0`. https://rise4fun.com/Alive/WMk https://rise4fun.com/Alive/udv Was mentioned in D47428 review. We already handle the `0` constant, https://godbolt.org/g/UZq1sJ, so this only handles negative constants. Could use computeKnownBits() / LazyValueInfo, but the cost-benefit analysis (https://reviews.llvm.org/D47891) suggests it isn't worth it. Reviewers: spatel, craig.topper Reviewed By: spatel Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47883 llvm-svn: 334222
* [NFC][InstSimplify] Add more tests for shl nuw C, %x -> C fold.Roman Lebedev2018-06-071-0/+86
| | | | | | | Follow-up for rL334200. For these, KnownBits will be needed. llvm-svn: 334206
* [NFC][InstSimplify] Add tests for shl nuw C, %x -> C fold.Roman Lebedev2018-06-071-0/+123
| | | | | | | | | | | | | | %r = shl nuw i8 C, %x As per langref: If the nuw keyword is present, then the shift produces a poison value if it shifts out any non-zero bits. Thus, if the sign bit is set on C, then %x can only be 0, which means that %r can only be C. https://rise4fun.com/Alive/WMk Was mentioned in D47428 review. llvm-svn: 334200
* [InstCombine] move misplaced test file and regenerate checks; NFCSanjay Patel2018-05-221-48/+0
| | | | llvm-svn: 333039
* [InstCombine] choose 1 form of abs and nabs as canonicalSanjay Patel2018-05-201-4/+4
| | | | | | | | | | | | | | | We already do this for min/max (see the blob above the diff), so we should do the same for abs/nabs. A sign-bit check (<s 0) is used as a predicate for other IR transforms and it's likely the best for codegen. This might solve the motivating cases for D47037 and D47041, but I think those patches still make sense. We can't guarantee this canonicalization if the icmp has more than one use. Differential Revision: https://reviews.llvm.org/D47076 llvm-svn: 332819
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* Reland r301880(!): "[InstSimplify] Handle selects of GEPs with 0 offset"George Burgess IV2018-04-241-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was reminded today that this patch got reverted in r301885. I can no longer reproduce the failure that caused the revert locally (...almost one year later), and the patch applied pretty cleanly, so I guess we'll see if the bots still get angry about it. The original breakage was InstSimplify complaining (in "assertion failed" form) about getting passed some crazy IR when running `ninja check-sanitizer`. I'm unable to find traces of what, exactly, said crazy IR was. I suppose we'll find out pretty soon if that's still the case. :) Original commit: Author: gbiv Date: Mon May 1 18:12:08 2017 New Revision: 301880 URL: http://llvm.org/viewvc/llvm-project?rev=301880&view=rev Log: [InstSimplify] Handle selects of GEPs with 0 offset In particular (since it wouldn't fit nicely in the summary): (select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V) Differential Revision: https://reviews.llvm.org/D31435 llvm-svn: 330667
* [PatternMatch] allow undef elements when matching a vector zeroSanjay Patel2018-04-227-31/+11
| | | | | | | | | | | | | | | | | | | | | | | | | This is the last step in getting constant pattern matchers to allow undef elements in constant vectors. I'm adding a dedicated m_ZeroInt() function and building m_Zero() from that. In most cases, calling code can be updated to use m_ZeroInt() directly when there's no need to match pointers, but I'm leaving that efficiency optimization as a follow-up step because it's not always clear when that's ok. There are just enough icmp folds in InstSimplify that can be used for integer or pointer types, that we probably still want a generic m_Zero() for those cases. Otherwise, we could eliminate it (and possibly add a m_NullPtr() as an alias for isa<ConstantPointerNull>()). We're conservatively returning a full zero vector (zeroinitializer) in InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify), but I'm not sure if that's actually necessary in all cases. We may be able to propagate an undef lane instead. One test where this happens is marked with 'TODO'. llvm-svn: 330550
* [InstSimplify, InstCombine] add vector tests with undef elts; NFCSanjay Patel2018-04-222-25/+60
| | | | llvm-svn: 330543
* [InstSimplify] move tests for shifts; NFCSanjay Patel2018-04-212-8/+107
| | | | llvm-svn: 330516
* [InstSimplify] move/add/regenerate checks for tests; NFCSanjay Patel2018-04-214-10/+90
| | | | llvm-svn: 330515
* [PatternMatch] allow undef elements when matching vector FP +0.0Sanjay Patel2018-03-252-6/+3
| | | | | | | | | | | | | This continues the FP constant pattern matching improvements from: https://reviews.llvm.org/rL327627 https://reviews.llvm.org/rL327339 https://reviews.llvm.org/rL327307 Several integer constant matchers also have this ability. I'm separating matching of integer/pointer null from FP positive zero and renaming/commenting to make the functionality clearer. llvm-svn: 328461
OpenPOWER on IntegriCloud