summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/InstructionSimplify.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merging r339515:Hans Wennborg2018-08-171-3/+3
| | | | | | | | | | | | | ------------------------------------------------------------------------ r339515 | d0k | 2018-08-12 13:43:03 +0200 (Sun, 12 Aug 2018) | 4 lines [InstSimplify] Guard against large shift amounts. 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: 339985
* Merging r338817:Hans Wennborg2018-08-071-0/+34
| | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r338817 | inouehrs | 2018-08-03 07:39:48 +0200 (Fri, 03 Aug 2018) | 10 lines [InstSimplify] fold extracting from std::pair (2/2) 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: 339097
* [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
* [InstSimplify] loosen FMF for sqrt(X) * sqrt(X) --> XSanjay Patel2018-03-181-3/+6
| | | | | | | | | As shown in the code comment, we don't need all of 'fast', but we do need reassoc + nsz + nnan. Differential Revision: https://reviews.llvm.org/D43765 llvm-svn: 327796
* [InstSimplify] peek through unsigned FP casts for sign-bit compares (PR36682)Roman Lebedev2018-03-151-0/+12
| | | | | | | | | | | | | | | | | | | This pattern came up in PR36682 / D44390 https://bugs.llvm.org/show_bug.cgi?id=36682 https://reviews.llvm.org/D44390 https://godbolt.org/g/oKvT5H See also D44421, D44424 Reviewers: spatel, majnemer, efriedma, arsenm Reviewed By: spatel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D44425 llvm-svn: 327642
* [InstSimplify][NFC] simplifyICmpWithConstant(): refactor GetCompareTy() callsRoman Lebedev2018-03-151-4/+6
| | | | | | Preparation for D44425. llvm-svn: 327641
* [ConstantFolding, InstSimplify] Handle more vector GEPsMatthew Simpson2018-03-151-2/+2
| | | | | | | | | | This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116. Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116 llvm-svn: 327638
* [PatternMatch, InstSimplify] allow undef elements when matching any vector ↵Sanjay Patel2018-03-151-8/+8
| | | | | | | | | | | FP zero This matcher implementation appears to be slightly more efficient than the generic constant check that it is replacing because every use was for matching FP patterns, but the previous code would check int and pointer type nulls too. llvm-svn: 327627
* [InstSimplify] remove 'nsz' requirement for frem 0, XSanjay Patel2018-03-151-5/+11
| | | | | | | | | | | From the LangRef definition for frem: "The value produced is the floating-point remainder of the two operands. This is the same output as a libm ‘fmod‘ function, but without any possibility of setting errno. The remainder has the same sign as the dividend. This instruction is assumed to execute in the default floating-point environment." llvm-svn: 327626
* [InstSimplify] fix folds for (0.0 - X) + X --> 0 (PR27151)Sanjay Patel2018-03-141-14/+10
| | | | | | | | | | | | | | | | As shown in: https://bugs.llvm.org/show_bug.cgi?id=27151 ...the existing fold could miscompile when X is NaN. The fold was also dependent on 'ninf' but that's not necessary. From IEEE-754 (with default rounding which we can assume for these opcodes): "When the sum of two operands with opposite signs (or the difference of two operands with like signs) is exactly zero, the sign of that sum (or difference) shall be +0...However, x + x = x − (−x) retains the same sign as x even when x is zero." llvm-svn: 327575
* [InstSimplify] fp_binop X, undef --> NaNSanjay Patel2018-03-101-14/+13
| | | | | | The variable operand could be NaN, so it's always safe to propagate NaN. llvm-svn: 327212
* [InstSimplify] remove redundant foldsSanjay Patel2018-03-051-18/+0
| | | | | | | | | | | | The 'hasOneUse' check is a giveaway that something's not right. We never need to check that in InstSimplify because we don't create new instructions here. These are all handled as icmp simplifies which then trigger existing select simplifies, so there's no need to duplicate a composite fold of the two. llvm-svn: 326750
* [PatternMatch, InstSimplify] fix m_NaN to work with vector constants and use itSanjay Patel2018-03-021-9/+6
| | | | | | | | | This is NFC for the moment (and independent of any potential NaN semantic controversy). Besides making the code in InstSimplify easier to read, the motivation is to eventually allow undef elements in vector constants to match too. A proposal to add the base logic for that is in D43792. llvm-svn: 326600
* [InstSimplify] sqrt(X) * sqrt(X) --> XSanjay Patel2018-02-231-0/+6
| | | | | | This was misplaced in InstCombine. We can loosen the FMF as a follow-up step. llvm-svn: 325965
* [PatternMatch, InstSimplify] enhance m_AllOnes() to ignore undef elements in ↵Sanjay Patel2018-02-181-11/+7
| | | | | | | | | | | | | | | | | | | vectors Loosening the matcher definition reveals a subtle bug in InstSimplify (we should not assume that because an operand constant matches that it's safe to return it as a result). So I'm making that change here too (that diff could be independent, but I'm not sure how to reveal it before the matcher change). This also seems like a good reason to *not* include matchers that capture the value. We don't want to encourage the potential misstep of propagating undef values when it's not allowed/intended. I didn't include the capture variant option here or in the related rL325437 (m_One), but it already exists for other constant matchers. llvm-svn: 325466
* [InstSimplify] move select undef cond fold with other constant cond folds; NFCISanjay Patel2018-02-171-20/+21
| | | | llvm-svn: 325434
* Adding a width of the GEP index to the Data Layout.Elena Demikhovsky2018-02-141-5/+5
| | | | | | | | | | | | | | | | | | 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
* [InstSimplify] allow exp/log simplifications with only 'reassoc' FMFSanjay Patel2018-02-121-4/+4
| | | | | | | | | | These intrinsic folds were added with D41381, but only allowed with isFast(). That's more than necessary because FMF has 'reassoc' to apply to these kinds of folds after D39304, and that's all we need in these cases. Differential Revision: https://reviews.llvm.org/D43160 llvm-svn: 324967
* [InstSimplify] (X * Y) / Y --> X for relaxed floating-point opsSanjay Patel2018-01-301-0/+6
| | | | | | | | | This is the FP counterpart that was mentioned in PR35709: https://bugs.llvm.org/show_bug.cgi?id=35709 Differential Revision: https://reviews.llvm.org/D42385 llvm-svn: 323716
* InstSimplify: If divisor element is undef simplify to undefZvi Rackover2018-01-241-2/+3
| | | | | | | | | | | | | | | | Summary: If any vector divisor element is undef, we can arbitrarily choose it be zero which would make the div/rem an undef value by definition. Reviewers: spatel, reames Reviewed By: spatel Subscribers: magabari, llvm-commits Differential Revision: https://reviews.llvm.org/D42485 llvm-svn: 323343
* [InstSimplify] (X << Y) % X -> 0Anton Bikineev2018-01-231-0/+7
| | | | llvm-svn: 323182
* [InstSimplify] use m_Specific and commutative matcher to reduce code; NFCISanjay Patel2018-01-191-9/+8
| | | | llvm-svn: 322955
* [InstSimplify] fix code comments; NFCSanjay Patel2018-01-141-8/+8
| | | | llvm-svn: 322456
* [InstSimplify] fold implied null ptr check (PR35790)Sanjay Patel2018-01-131-15/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | This extends rL322327 to handle the pointer cast and should solve: https://bugs.llvm.org/show_bug.cgi?id=35790 Name: or_eq_zero %isnull = icmp eq i64* %p, null %x = ptrtoint i64* %p to i64 %somebits = and i64 %x, %y %somebits_are_zero = icmp eq i64 %somebits, 0 %or = or i1 %somebits_are_zero, %isnull => %or = %somebits_are_zero Name: and_ne_zero %isnotnull = icmp ne i64* %p, null %x = ptrtoint i64* %p to i64 %somebits = and i64 %x, %y %somebits_are_not_zero = icmp ne i64 %somebits, 0 %and = and i1 %somebits_are_not_zero, %isnotnull => %and = %somebits_are_not_zero https://rise4fun.com/Alive/CQ3 llvm-svn: 322439
* [InstSimplify] fold implied cmp with zero (PR35790)Sanjay Patel2018-01-111-0/+42
| | | | | | | | | This doesn't handle the more complicated case in the bug report yet: https://bugs.llvm.org/show_bug.cgi?id=35790 For that, we have to match / look through a cast. llvm-svn: 322327
* [InstSimplify] Missed optimization in math expression: squashing exp(log), ↵Dmitry Venikov2018-01-031-6/+33
| | | | | | | | | | | | | | | | log(exp) Summary: This patch enables folding following expressions under -ffast-math flag: exp(log(x)) -> x, exp2(log2(x)) -> x, log(exp(x)) -> x, log2(exp2(x)) -> x Reviewers: spatel, hfinkel, davide Reviewed By: spatel, hfinkel, davide Subscribers: scanon, llvm-commits Differential Revision: https://reviews.llvm.org/D41381 llvm-svn: 321710
* Test commitDmitry Venikov2018-01-021-1/+1
| | | | | | | | | | Reviewers: Quolyk Reviewed By: Quolyk Differential Revision: https://reviews.llvm.org/D41561 llvm-svn: 321636
* [instsimplify] consistently handle undef and out of bound indices for ↵Philip Reames2017-12-301-6/+10
| | | | | | | | | | insertelement and extractelement In one case, we were handling out of bounds, but not undef indices. In the other, we were handling undef (with the comment making the analogy to out of bounds), but not out of bounds. Be consistent and treat both undef and constant out of bounds indices as producing undefined results. As a side effect, this also protects instcombine from having to handle large constant indices as we always simplify first. llvm-svn: 321575
OpenPOWER on IntegriCloud