summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC][InstSimplify] Add extra test for D67411 with @llvm.assumeRoman Lebedev2019-09-111-0/+21
| | | | llvm-svn: 371629
* LLVM: Optimization Pass: Remove conflicting attribute, if any, beforeWhitney Tsang2019-09-111-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | adding new read attribute to an argument Summary: Update optimization pass to prevent adding read-attribute to an argument without removing its conflicting attribute. A read attribute, based on the result of the attribute deduction process, might be added to an argument. The attribute might be in conflict with other read/write attribute currently associated with the argument. To ensure the compatibility of attributes, conflicting attribute, if any, must be removed before a new one is added. The following snippet shows the current behavior of the compiler, where the compilation process is aborted due to incompatible attributes. $ cat x.ll ; ModuleID = 'x.bc' %_type_of_d-ccc = type <{ i8*, i8, i8, i8, i8 }> @d-ccc = internal global %_type_of_d-ccc <{ i8* null, i8 1, i8 13, i8 0, i8 -127 }>, align 8 define void @foo(i32* writeonly %.aaa) { foo_entry: %_param_.aaa = alloca i32*, align 8 store i32* %.aaa, i32** %_param_.aaa, align 8 store i8 0, i8* getelementptr inbounds (%_type_of_d-ccc, %_type_of_d-ccc* @d-ccc, i32 0, i32 3) ret void } $ opt -O3 x.ll Attributes 'readnone and writeonly' are incompatible! void (i32*)* @foo in function foo LLVM ERROR: Broken function found, compilation aborted! The purpose of this changeset is to fix the above error. This fix is based on a suggestion from Johannes @jdoerfert (many thanks!!!) Authored By: anhtuyen Reviewer: nicholas, rnk, chandlerc, jdoerfert Reviewed By: rnk Subscribers: hiraditya, jdoerfert, llvm-commits, anhtuyen, LLVM Tag: LLVM Differential Revision: https://reviews.llvm.org/D58694 llvm-svn: 371622
* [ConstProp] add tests for fma that produce NaN; NFCSanjay Patel2019-09-111-0/+133
| | | | llvm-svn: 371621
* [ConstProp] move test file from InstSimplify; NFCSanjay Patel2019-09-111-1/+1
| | | | | | | 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
* [InstCombine] fold sign-bit compares of sremSanjay Patel2019-09-111-8/+20
| | | | | | | | | | | | | | | | | (srem X, pow2C) sgt/slt 0 can be reduced using bit hacks by masking off the sign bit and the module (low) bits: https://rise4fun.com/Alive/jSO A '2' divisor allows slightly more folding: https://rise4fun.com/Alive/tDBM Any chance to remove an 'srem' use is probably worthwhile, but this is limited to the one-use improvement case because doing more may expose other missing folds. That means it does nothing for PR21929 yet: https://bugs.llvm.org/show_bug.cgi?id=21929 Differential Revision: https://reviews.llvm.org/D67334 llvm-svn: 371610
* [NFC] Updated objsize-64.ll testDavid Bolvansky2019-09-111-1/+1
| | | | llvm-svn: 371604
* [NFC] Fixed testDavid Bolvansky2019-09-111-2/+2
| | | | llvm-svn: 371603
* [InstCombine] Fixed handling of isOpNewLike (PR11748)David Bolvansky2019-09-111-1/+11
| | | | llvm-svn: 371602
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-1111-1042/+14
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* [LoopInterchange] Properly move condition, induction increment and ops to latch.Florian Hahn2019-09-115-27/+216
| | | | | | | | | | | | | | | | | | | | | | | Currently we only rely on the induction increment to come before the condition to ensure the required instructions get moved to the new latch. This patch duplicates and moves the required instructions to the newly created latch. We move the condition to the end of the new block, then process its operands. We stop at operands that are defined outside the loop, or are the induction PHI. We duplicate the instructions and update the uses in the moved instructions, to ensure other users remain intact. See the added test2 for such an example. Reviewers: efriedma, mcrosier Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D67367 llvm-svn: 371595
* [TLI][AMDGPU] AMDPAL does not have library functionsTim Renouf2019-09-111-0/+21
| | | | | | | | | | | Configure TLI to say that r600/amdgpu does not have any library functions, such that InstCombine does not do anything like turn sin/cos into the library function @tan with sufficient fast math flags. Differential Revision: https://reviews.llvm.org/D67406 Change-Id: I02f907d3e64832117ea9800e9f9285282856e5df llvm-svn: 371592
* [Attributor] Implement "noalias" callsite argument deductionHideto Ueno2019-09-111-0/+76
| | | | | | | | | | | | | | | | Summary: Now, `nocapture` is deduced in Attributor therefore, this patch introduces deduction for `noalias` callsite argument using `nocapture`. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: lebedev.ri, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67286 llvm-svn: 371590
* [Debuginfo][Instcombiner] Do not clone dbg.declare.Alexey Lapshin2019-09-111-0/+144
| | | | | | | | | | | | TryToSinkInstruction() has a bug: While updating debug info for sunk instruction, it could clone dbg.declare intrinsic. That is wrong. There could be only one dbg.declare. The fix is to not clone dbg.declare intrinsic and to update it`s arguments, to not to point to sunk instruction. Differential Revision: https://reviews.llvm.org/D67217 llvm-svn: 371587
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-1111-14/+1042
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Reland "Change the X86 datalayout to add three address spacesAmy Huang2019-09-1072-72/+72
| | | | | | | | | | for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568
* [NFC][InstCombine] rewrite test added in r371537 to use non-null pointer insteadRoman Lebedev2019-09-101-27/+91
| | | | | | | | 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: 371550
* [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-102-1/+141
| | | | | | https://rise4fun.com/Alive/21b llvm-svn: 371537
* [NFC][InstCombine] PR43251 - valid for other predicates tooRoman Lebedev2019-09-101-2/+82
| | | | llvm-svn: 371519
* [InstCombine] Use SimplifyFMulInst to simplify multiply in fma.Florian Hahn2019-09-101-10/+5
| | | | | | | | | | | | | | This allows us to fold fma's that multiply with 0.0. Also, the multiply by 1.0 case is handled there as well. The fneg/fabs cases are not handled by SimplifyFMulInst, so we need to keep them. Reviewers: spatel, anemet, lebedev.ri Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D67351 llvm-svn: 371518
* [InstCombine] Precommit tests for D67351.Florian Hahn2019-09-101-0/+86
| | | | llvm-svn: 371517
* Revert "Reland "r364412 [ExpandMemCmp][MergeICmps] Move passes out of ↵Dmitri Gribenko2019-09-1013-2032/+3
| | | | | | | | | CodeGen into opt pipeline."" This reverts commit r371502, it broke tests (clang/test/CodeGenCXX/auto-var-init.cpp). llvm-svn: 371507
* [ExpandMemCmp] Add lit.local.cfgClement Courbet2019-09-101-0/+3
| | | | | | | | | | | To prevent AArch64 tests from running when the target is not compiled. Fixes r371502: /home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/test/Transforms/ExpandMemCmp/AArch64/memcmp.ll:11:15: error: CHECK-NEXT: expected string not found in input ; CHECK-NEXT: [[TMP0:%.*]] = bitcast i8* [[S1:%.*]] to i64* llvm-svn: 371503
* Reland "r364412 [ExpandMemCmp][MergeICmps] Move passes out of CodeGen into ↵Clement Courbet2019-09-1013-3/+2032
| | | | | | | | opt pipeline." With a fix for sanitizer breakage (see explanation in D60318). llvm-svn: 371502
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-1011-1042/+14
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-1011-14/+1042
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [Tests] Fix a typo in a testPhilip Reames2019-09-091-83/+96
| | | | llvm-svn: 371456
* [Tests] Precommit test case for D67372Philip Reames2019-09-091-10/+302
| | | | llvm-svn: 371455
* [LoopVectorize] Leverage speculation safety to avoid masked.loadsPhilip Reames2019-09-092-18/+18
| | | | | | | | | | | | If we're vectorizing a load in a predicated block, check to see if the load can be speculated rather than predicated. This allows us to generate a normal vector load instead of a masked.load. To do so, we must prove that all bytes accessed on any iteration of the original loop are dereferenceable, and that all loads (across all iterations) are properly aligned. This is equivelent to proving that hoisting the load into the loop header in the original scalar loop is safe. Note: There are a couple of code motion todos in the code. My intention is to wait about a day - to be sure this sticks - and then perform the NFC motion without furthe review. Differential Revision: https://reviews.llvm.org/D66688 llvm-svn: 371452
* [SLP] add test for over-vectorization (PR33958); NFCSanjay Patel2019-09-091-0/+16
| | | | llvm-svn: 371426
* [NFC][InstCombine] Fixup test i added in rL371352.Roman Lebedev2019-09-091-2/+2
| | | | llvm-svn: 371401
* [Inliner][NFC] Make test less brittle.Clement Courbet2019-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This tests inlining size thresholds, but relies on the output of running the full O2 pipeline, making it brittle against changes in unrelated passes. Only run the inlining pass and set thresholds on the test RUN line instead. Found while investigating D60318. Reviewers: RKSimon, qcolombet Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67349 llvm-svn: 371397
* [InstCombine][NFC] Some tests for usub overflow+nonzero check improvement ↵Roman Lebedev2019-09-081-0/+343
| | | | | | | | | | (PR43251) https://rise4fun.com/Alive/kHq https://bugs.llvm.org/show_bug.cgi?id=43251 llvm-svn: 371352
* [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
* [InstCombine] add tests for icmp with srem operand; NFCSanjay Patel2019-09-081-16/+108
| | | | llvm-svn: 371348
* [InstCombine] fold extract+insert into identity shuffleSanjay Patel2019-09-081-8/+9
| | | | | | | | | | | | | | | This is similar to the existing fold for splats added with: rL365379 If we can adjust the shuffle mask to include another element in an identity mask (if it changes vector length, that's an extract/insert subvector operation in the backend), then that can eliminate extractelement/insertelement pairs in IR. All targets are expected to lower shuffles with identity masks efficiently. llvm-svn: 371340
* [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
* [X86] Add prefer-128-bit subtarget feature.Craig Topper2019-09-074-9/+17
| | | | | | | | | | | | | | | | | | | Summary: Similar to the previous prefer-256-bit flag. We might want to enable this by default some CPUs. This just starts the initial work to implement and prove that it effects TTI's vector width. Reviewers: RKSimon, echristo, spatel, atdt Reviewed By: RKSimon Subscribers: lebedev.ri, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67311 llvm-svn: 371319
* [SimplifyCFG][NFC] Autogenerate PhiEliminate3.llRoman Lebedev2019-09-071-22/+71
| | | | llvm-svn: 371311
* [SimplifyCFG][NFC] Autogenerate two testsRoman Lebedev2019-09-072-26/+89
| | | | llvm-svn: 371310
* [Intrinsic] Add the llvm.umul.fix.sat intrinsicBjorn Pettersson2019-09-071-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. The result is saturated and clamped between the largest and smallest representable values of the first 2 operands. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Patch by: leonardchan, bjope Reviewers: RKSimon, craig.topper, bevinh, leonardchan, lebedev.ri, spatel Reviewed By: leonardchan Subscribers: ychen, wuzish, nemanjai, MaskRay, jsji, jdoerfert, Ka-Ka, hiraditya, rjmccall, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57836 llvm-svn: 371308
* [LVI] Look through extractvalue of insertvalueNikita Popov2019-09-071-20/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This addresses the issue mentioned on D19867. When we simplify with.overflow instructions in CVP, we leave behind extractvalue of insertvalue sequences that LVI no longer understands. This means that we can not simplify any instructions based on the with.overflow anymore (until some over pass like InstCombine cleans them up). This patch extends LVI extractvalue handling by calling SimplifyExtractValueInst (which doesn't do anything more than constant folding + looking through insertvalue) and using the block value of the simplification. A possible alternative would be to do something similar to SimplifyIndVars, where we instead directly try to replace extractvalue users of the with.overflow. This would need some additional structural changes to CVP, as it's currently not legal to remove anything but the current instruction -- we'd have to introduce a worklist with instructions scheduled for deletion or similar. Differential Revision: https://reviews.llvm.org/D67035 llvm-svn: 371306
* [SimplifyCFG][NFC] Make merge-cond-stores-cost.ll X86-specific, and rewrite itRoman Lebedev2019-09-072-37/+51
| | | | | | We clearly perform store-merging, even though div is really costly. llvm-svn: 371300
* [SimplifyCFG][NFC] Show that we don't consider the cost when merging cond storesRoman Lebedev2019-09-071-0/+36
| | | | | | We count instruction count in each BB's separately, not their cost. llvm-svn: 371297
* [SimplifyCFG][NFC] Regenerate merge-cond-stores* testsRoman Lebedev2019-09-072-54/+65
| | | | llvm-svn: 371296
* [Attributor] ValueSimplify Abstract AttributeHideto Ueno2019-09-074-3/+124
| | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces initial `AAValueSimplify` which simplifies a value in a context. example - (for function returned) If all the return values are the same and constant, then we can replace callsite returned with the constant. - If an internal function takes the same value(constant) as an argument in the callsite, then we can replace the argument with that constant. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66967 llvm-svn: 371291
* [X86] Replace -mcpu with -mattr on some tests.Craig Topper2019-09-062-5/+4
| | | | llvm-svn: 371260
* [InstCombine] pow(x, +/- 0.0) -> 1.0JF Bastien2019-09-061-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This isn't an important optimization at all... We're already doing: pow(x, 0.0) -> 1.0 My patch merely teaches instcombine that -0.0 does the same. However, doing this fixes an AMAZING bug! Compile this program: extern "C" double pow(double, double); double boom(double base) { return pow(base, -0.0); } With: clang++ ~/Desktop/fast-math.cpp -ffast-math -O2 -S And clang will crash with a signal. Wow, fast math is so fast it ICEs the compiler! Arguably, the generated math is infinitely fast. What's actually happening is that we recurse infinitely in getPow. In debug we hit its assertion: assert(Exp != 0 && "Incorrect exponent 0 not handled"); We avoid this entire mess if we instead recognize that an exponent of positive and negative zero yield 1.0. A separate commit, r371221, fixed the same problem. This only contains the added tests. <rdar://problem/54598300> Reviewers: scanon Subscribers: hiraditya, jkorous, dexonsmith, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67248 llvm-svn: 371224
* [SimplifyLibCalls] handle pow(x,-0.0) before it can assert (PR43233)Sanjay Patel2019-09-061-0/+10
| | | | | | https://bugs.llvm.org/show_bug.cgi?id=43233 llvm-svn: 371221
OpenPOWER on IntegriCloud