summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/InstructionSimplify.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [InstSimplify] Simplify saturating add/sub + icmpNikita Popov2018-12-171-0/+66
| | | | | | | | | | | | | If a saturating add/sub has one constant operand, then we can determine the possible range of outputs it can produce, and simplify an icmp comparison based on that. The implementation is based on a similar existing mechanism for simplifying binary operator + icmps. Differential Revision: https://reviews.llvm.org/D55735 llvm-svn: 349369
* [ValueTracking] add helper function for testing implied condition; NFCISanjay Patel2018-12-021-38/+3
| | | | | | | | We were duplicating code around the existing isImpliedCondition() that checks for a predecessor block/dominating condition, so make that a wrapper call. llvm-svn: 348088
* [InstSimplify] fold select with implied conditionSanjay Patel2018-11-291-0/+39
| | | | | | | | | | | | | | | | | | | | | | | This is an almost direct move of the functionality from InstCombine to InstSimplify. There's no reason not to do this in InstSimplify because we never create a new value with this transform. (There's a question of whether any dominance-based transform belongs in either of these passes, but that's a separate issue.) I've changed 1 of the conditions for the fold (1 of the blocks for the branch must be the block we started with) into an assert because I'm not sure how that could ever be false. We need 1 extra check to make sure that the instruction itself is in a basic block because passes other than InstCombine may be using InstSimplify as an analysis on values that are not wired up yet. The 3-way compare changes show that InstCombine has some kind of phase-ordering hole. Otherwise, we would have already gotten the intended final result that we now show here. llvm-svn: 347896
* [InstSimplify] fold funnel shifts with undef operandsSanjay Patel2018-11-201-1/+10
| | | | | | | | Splitting these off from the D54666. Patch by: nikic (Nikita Popov) llvm-svn: 347332
* [InstructionSimplify] Add support for saturating add/subSanjay Patel2018-11-201-0/+34
| | | | | | | | | | | | | | | | | | | | | | Add support for saturating add/sub in InstructionSimplify. In particular, the following simplifications are supported: sat(X + 0) -> X sat(X + undef) -> -1 sat(X uadd MAX) -> MAX (and commutative variants) sat(X - 0) -> X sat(X - X) -> 0 sat(X - undef) -> 0 sat(undef - X) -> 0 sat(0 usub X) -> 0 sat(X usub MAX) -> 0 Patch by: @nikic (Nikita Popov) Differential Revision: https://reviews.llvm.org/D54532 llvm-svn: 347330
* [InstSimplify] delete shift-of-zero guard ops around funnel shiftsSanjay Patel2018-11-151-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | This is a problem seen in common rotate idioms as noted in: https://bugs.llvm.org/show_bug.cgi?id=34924 Note that we are not canonicalizing standard IR (shifts and logic) to the intrinsics yet. (Although I've written this before...) I think this is the last step before we enable that transform. Ie, we could regress code by doing that transform without this simplification in place. In PR34924, I questioned whether this is a valid transform for target-independent IR, but I convinced myself this is ok. If we're speculating a funnel shift by turning cmp+br into select, then SimplifyCFG has already determined that the transform is justified. It's possible that SimplifyCFG is not taking into account profile or other metadata, but if that's true, then it's a bug independent of funnel shifts. Also, we do have CGP code to restore a guard like this around an intrinsic if it can't be lowered cheaply. But that isn't necessary for funnel shift because the default expansion in SelectionDAGBuilder includes this same cmp+select. Differential Revision: https://reviews.llvm.org/D54552 llvm-svn: 346960
* [InstSimplify] fold select (fcmp X, Y), X, YSanjay Patel2018-11-051-0/+31
| | | | | | | | | This is NFCI for InstCombine because it calls InstSimplify, so I left the tests for this transform there. As noted in the code comment, we can allow this fold more often by using FMF and/or value tracking. llvm-svn: 346169
* [InstSimplify] fold icmp based on range of abs/nabs (2nd try)Sanjay Patel2018-11-011-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is retrying the fold from rL345717 (reverted at rL347780) ...with a fix for the miscompile demonstrated by PR39510: https://bugs.llvm.org/show_bug.cgi?id=39510 Original commit message: This is a fix for PR39475: https://bugs.llvm.org/show_bug.cgi?id=39475 We managed to get some of these patterns using computeKnownBits in https://reviews.llvm.org/D47041, but that can't be used for nabs(). Instead, put in some range-based logic, so we can fold both abs/nabs with icmp with a constant value. Alive proofs: https://rise4fun.com/Alive/21r Name: abs_nsw_is_positive %cmp = icmp slt i32 %x, 0 %negx = sub nsw i32 0, %x %abs = select i1 %cmp, i32 %negx, i32 %x %r = icmp sgt i32 %abs, -1 => %r = i1 true Name: abs_nsw_is_not_negative %cmp = icmp slt i32 %x, 0 %negx = sub nsw i32 0, %x %abs = select i1 %cmp, i32 %negx, i32 %x %r = icmp slt i32 %abs, 0 => %r = i1 false Name: nabs_is_negative_or_0 %cmp = icmp slt i32 %x, 0 %negx = sub i32 0, %x %nabs = select i1 %cmp, i32 %x, i32 %negx %r = icmp slt i32 %nabs, 1 => %r = i1 true Name: nabs_is_not_over_0 %cmp = icmp slt i32 %x, 0 %negx = sub i32 0, %x %nabs = select i1 %cmp, i32 %x, i32 %negx %r = icmp sgt i32 %nabs, 0 => %r = i1 false Differential Revision: https://reviews.llvm.org/D53844 llvm-svn: 345832
* revert rL345717 : [InstSimplify] fold icmp based on range of abs/nabsSanjay Patel2018-10-311-42/+0
| | | | | | | This can miscompile as shown in PR39510: https://bugs.llvm.org/show_bug.cgi?id=39510 llvm-svn: 345780
* [InstSimplify] fold 'fcmp nnan ult X, 0.0' when X is not negativeSanjay Patel2018-10-311-1/+4
| | | | | | This is the inverted case for the transform added with D53874 / rL345725. llvm-svn: 345728
* [InstSimplify] fold 'fcmp nnan oge X, 0.0' when X is not negativeSanjay Patel2018-10-311-0/+4
| | | | | | | | | | | | | | This re-raises some of the open questions about how to apply and use fast-math-flags in IR from PR38086: https://bugs.llvm.org/show_bug.cgi?id=38086 ...but given the current implementation (no FMF on casts), this is likely the only way to predicate the transform. This is part of solving PR39475: https://bugs.llvm.org/show_bug.cgi?id=39475 Differential Revision: https://reviews.llvm.org/D53874 llvm-svn: 345725
* [InstSimplify] fold icmp based on range of abs/nabsSanjay Patel2018-10-311-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR39475: https://bugs.llvm.org/show_bug.cgi?id=39475 We managed to get some of these patterns using computeKnownBits in D47041, but that can't be used for nabs(). Instead, put in some range-based logic, so we can fold both abs/nabs with icmp with a constant value. Alive proofs: https://rise4fun.com/Alive/21r Name: abs_nsw_is_positive %cmp = icmp slt i32 %x, 0 %negx = sub nsw i32 0, %x %abs = select i1 %cmp, i32 %negx, i32 %x %r = icmp sgt i32 %abs, -1 => %r = i1 true Name: abs_nsw_is_not_negative %cmp = icmp slt i32 %x, 0 %negx = sub nsw i32 0, %x %abs = select i1 %cmp, i32 %negx, i32 %x %r = icmp slt i32 %abs, 0 => %r = i1 false Name: nabs_is_negative_or_0 %cmp = icmp slt i32 %x, 0 %negx = sub i32 0, %x %nabs = select i1 %cmp, i32 %x, i32 %negx %r = icmp slt i32 %nabs, 1 => %r = i1 true Name: nabs_is_not_over_0 %cmp = icmp slt i32 %x, 0 %negx = sub i32 0, %x %nabs = select i1 %cmp, i32 %x, i32 %negx %r = icmp sgt i32 %nabs, 0 => %r = i1 false Differential Revision: https://reviews.llvm.org/D53844 llvm-svn: 345717
* [InstCombine] InstCombine and InstSimplify for minimum and maximumThomas Lively2018-10-191-7/+18
| | | | | | | | | | | | Summary: Depends on D52765 Reviewers: aheejin, dschuff Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D52766 llvm-svn: 344799
* [FPEnv] PatternMatcher support for checking FNEG ignoring signed zerosCameron McInally2018-10-091-4/+2
| | | | | | https://reviews.llvm.org/D52934 llvm-svn: 344084
* [IR] Replace `isa<TerminatorInst>` with `isTerminator()`.Chandler Carruth2018-08-261-2/+2
| | | | | | | | | | | | This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
* [InstSimplify] use isKnownNeverNaN to fold more fcmp ord/unoSanjay Patel2018-08-211-7/+5
| | | | | | | | | | | Remove duplicate tests from InstCombine that were added with D50582. I left negative tests there to verify that nothing in InstCombine tries to go overboard. If isKnownNeverNaN is improved to handle the FP binops or other cases, we should have coverage under InstSimplify, so we could remove more duplicate tests from InstCombine at that time. llvm-svn: 340279
* [InstrSimplify,NewGVN] Add option to ignore additional instr info when ↵Florian Hahn2018-08-171-74/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | simplifying. NewGVN uses InstructionSimplify for simplifications of leaders of congruence classes. It is not guaranteed that the metadata or other flags/keywords (like nsw or exact) of the leader is available for all members in a congruence class, so we cannot use it for simplification. This patch adds a InstrInfoQuery struct with a boolean field UseInstrInfo (which defaults to true to keep the current behavior as default) and a set of helper methods to get metadata/keywords for a given instruction, if UseInstrInfo is true. The whole thing might need a better name, to avoid confusion with TargetInstrInfo but I am not sure what a better name would be. The current patch threads through InstrInfoQuery to the required places, which is messier then it would need to be, if InstructionSimplify and ValueTracking would share the same Query struct. The reason I added it as a separate struct is that it can be shared between InstructionSimplify and ValueTracking's query objects. Also, some places do not need a full query object, just the InstrInfoQuery. It also updates some interfaces that do not take a Query object, but a set of optional parameters to take an additional boolean UseInstrInfo. See https://bugs.llvm.org/show_bug.cgi?id=37540. Reviewers: dberlin, davide, efriedma, sebpop, hiraditya Reviewed By: hiraditya Differential Revision: https://reviews.llvm.org/D47143 llvm-svn: 340031
* [InstSimplify] Guard against large shift amounts.Benjamin Kramer2018-08-121-3/+3
| | | | | | | These are always UB, but can happen for large integer inputs. Testing it is very fragile as -simplifycfg will nuke the UB top-down. llvm-svn: 339515
* ValueTracking: Start enhancing isKnownNeverNaNMatt Arsenault2018-08-091-9/+11
| | | | llvm-svn: 339399
* [InstSimplify] move minnum/maxnum with Inf folds from instcombineSanjay Patel2018-08-091-1/+16
| | | | llvm-svn: 339396
* [InstSimplify] fold fsub+fadd with common operandSanjay Patel2018-08-071-0/+8
| | | | llvm-svn: 339176
* [InstSimplify] fold fadd+fsub with common operandSanjay Patel2018-08-071-1/+3
| | | | llvm-svn: 339174
* [InstSimplify] fold fsub+fsub with common operandSanjay Patel2018-08-071-0/+5
| | | | llvm-svn: 339171
* [InstSimplify] move minnum/maxnum with common op fold from instcombineSanjay Patel2018-08-071-0/+11
| | | | llvm-svn: 339144
* [InstSimplify] fold extracting from std::pair (2/2)Hiroshi Inoue2018-08-031-0/+34
| | | | | | | | | | | 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-3/+4
| | | | llvm-svn: 338719
* [InstSimplify] move minnum/maxnum with same arg fold from instcombineSanjay Patel2018-08-011-0/+3
| | | | llvm-svn: 338652
* [InstSimplify] fold extracting from std::pair (1/2)Hiroshi Inoue2018-08-011-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-311-14/+22
| | | | | | | | | | | | | | 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] fold funnel shifts with 0-shift amountSanjay Patel2018-07-291-0/+13
| | | | llvm-svn: 338218
* [InstSimplify] refactor intrinsic simplifications; NFCISanjay Patel2018-07-291-134/+116
| | | | llvm-svn: 338215
* [InstCombine] Fold Select with AND/OR conditionDavid Bolvansky2018-07-281-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fold ``` %A = icmp ne i8 %X, %V1 %B = icmp ne i8 %X, %V2 %C = or i1 %A, %B %D = select i1 %C, i8 %X, i8 %V1 ret i8 %D => ret i8 %X Fixes https://bugs.llvm.org/show_bug.cgi?id=38334 Proof: https://rise4fun.com/Alive/plI8 Reviewers: spatel, lebedev.ri Reviewed By: lebedev.ri Subscribers: craig.topper, llvm-commits Differential Revision: https://reviews.llvm.org/D49919 llvm-svn: 338191
* [InstrSimplify] fold sdiv if two operands are negated and non-overflowChen Zheng2018-07-211-1/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D49382 llvm-svn: 337642
* [InstSimplify] fold srem instruction if its two operands are negated.Chen Zheng2018-07-201-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D49423 llvm-svn: 337545
* [InstSimplify] fold minnum/maxnum with NaN argSanjay Patel2018-07-151-0/+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] simplify add instruction if two operands are negativeChen Zheng2018-07-121-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D49216 llvm-svn: 336881
* llvm: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-091-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+5
| | | | | | https://rise4fun.com/Alive/c3Y llvm-svn: 335633
* [InstSimplify] fold srem with sext bool divisorSanjay Patel2018-06-261-0/+6
| | | | llvm-svn: 335616
* [InstSimplify] fold div/rem of zexted boolSanjay Patel2018-06-251-1/+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] Fix missed optimization in simplifyUnsignedRangeCheck()Sanjay Patel2018-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* [NFC][InstSimplify] SimplifyAddInst(): coding style: variable names.Roman Lebedev2018-06-081-5/+5
| | | | llvm-svn: 334299
* [InstSimplify] add nuw %x, -1 -> -1 fold.Roman Lebedev2018-06-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [InstSimplify] shl nuw C, %x -> C iff signbit is set on C.Roman Lebedev2018-06-071-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* Reland r301880(!): "[InstSimplify] Handle selects of GEPs with 0 offset"George Burgess IV2018-04-241-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-221-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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] fix formatting; NFCSanjay Patel2018-04-101-7/+7
| | | | llvm-svn: 329736
* [PatternMatch] allow undef elements when matching vector FP +0.0Sanjay Patel2018-03-251-9/+10
| | | | | | | | | | | | | 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
* [InstSimplify] fp_binop X, NaN --> NaNSanjay Patel2018-03-211-10/+32
| | | | | | | | We propagate the existing NaN value when possible. Differential Revision: https://reviews.llvm.org/D44521 llvm-svn: 328140
OpenPOWER on IntegriCloud