summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Use new vector insert half-word and byte instructions when we see ↵Graham Yiu2017-11-071-0/+244
| | | | | | | | insertelement on '8 x i16' and '16 x i8' types. Also extended existing lit testcase to cover these cases. Differential Revision: https://reviews.llvm.org/D34630 llvm-svn: 317613
* Reland "Correct dwarf unwind information in function epilogue for X86"Petar Jovanovic2017-11-0787-17/+1215
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland r317100 with minor fix regarding ComputeCommonTailLength function in BranchFolding.cpp. Skipping top CFI instructions block needs to executed on several more return points in ComputeCommonTailLength(). Original r317100 message: "Correct dwarf unwind information in function epilogue for X86" This patch aims to provide correct dwarf unwind information in function epilogue for X86. It consists of two parts. The first part inserts CFI instructions that set appropriate cfa offset and cfa register in emitEpilogue() in X86FrameLowering. This part is X86 specific. The second part is platform independent and ensures that: - CFI instructions do not affect code generation - Unwind information remains correct when a function is modified by different passes. This is done in a late pass by analyzing information about cfa offset and cfa register in BBs and inserting additional CFI directives where necessary. Changed CFI instructions so that they: - are duplicable - are not counted as instructions when tail duplicating or tail merging - can be compared as equal Added CFIInstrInserter pass: - analyzes each basic block to determine cfa offset and register valid at its entry and exit - verifies that outgoing cfa offset and register of predecessor blocks match incoming values of their successors - inserts additional CFI directives at basic block beginning to correct the rule for calculating CFA Having CFI instructions in function epilogue can cause incorrect CFA calculation rule for some basic blocks. This can happen if, due to basic block reordering, or the existence of multiple epilogue blocks, some of the blocks have wrong cfa offset and register values set by the epilogue block above them. CFIInstrInserter is currently run only on X86, but can be used by any target that implements support for adding CFI instructions in epilogue. Patch by Violeta Vukobrat. llvm-svn: 317579
* [X86] Regenerate select testsSimon Pilgrim2017-11-071-34/+4
| | | | llvm-svn: 317571
* [GlobalISel] Enable legalizing non-power-of-2 sized types.Kristof Beyls2017-11-074-6/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the interface of how targets describe how to legalize, see the below description. 1. Interface for targets to describe how to legalize. In GlobalISel, the API in the LegalizerInfo class is the main interface for targets to specify which types are legal for which operations, and what to do to turn illegal type/operation combinations into legal ones. For each operation the type sizes that can be legalized without having to change the size of the type are specified with a call to setAction. This isn't different to how GlobalISel worked before. For example, for a target that supports 32 and 64 bit adds natively: for (auto Ty : {s32, s64}) setAction({G_ADD, 0, s32}, Legal); or for a target that needs a library call for a 32 bit division: setAction({G_SDIV, s32}, Libcall); The main conceptual change to the LegalizerInfo API, is in specifying how to legalize the type sizes for which a change of size is needed. For example, in the above example, how to specify how all types from i1 to i8388607 (apart from s32 and s64 which are legal) need to be legalized and expressed in terms of operations on the available legal sizes (again, i32 and i64 in this case). Before, the implementation only allowed specifying power-of-2-sized types (e.g. setAction({G_ADD, 0, s128}, NarrowScalar). A worse limitation was that if you'd wanted to specify how to legalize all the sized types as allowed by the LLVM-IR LangRef, i1 to i8388607, you'd have to call setAction 8388607-3 times and probably would need a lot of memory to store all of these specifications. Instead, the legalization actions that need to change the size of the type are specified now using a "SizeChangeStrategy". For example: setLegalizeScalarToDifferentSizeStrategy( G_ADD, 0, widenToLargerAndNarrowToLargest); This example indicates that for type sizes for which there is a larger size that can be legalized towards, do it by Widening the size. For example, G_ADD on s17 will be legalized by first doing WidenScalar to make it s32, after which it's legal. The "NarrowToLargest" indicates what to do if there is no larger size that can be legalized towards. E.g. G_ADD on s92 will be legalized by doing NarrowScalar to s64. Another example, taken from the ARM backend is: for (unsigned Op : {G_SDIV, G_UDIV}) { setLegalizeScalarToDifferentSizeStrategy(Op, 0, widenToLargerTypesUnsupportedOtherwise); if (ST.hasDivideInARMMode()) setAction({Op, s32}, Legal); else setAction({Op, s32}, Libcall); } For this example, G_SDIV on s8, on a target without a divide instruction, would be legalized by first doing action (WidenScalar, s32), followed by (Libcall, s32). The same principle is also followed for when the number of vector lanes on vector data types need to be changed, e.g.: setAction({G_ADD, LLT::vector(8, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(16, 8)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(8, 16)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(2, 32)}, LegalizerInfo::Legal); setAction({G_ADD, LLT::vector(4, 32)}, LegalizerInfo::Legal); setLegalizeVectorElementToDifferentSizeStrategy( G_ADD, 0, widenToLargerTypesUnsupportedOtherwise); As currently implemented here, vector types are legalized by first making the vector element size legal, followed by then making the number of lanes legal. The strategy to follow in the first step is set by a call to setLegalizeVectorElementToDifferentSizeStrategy, see example above. The strategy followed in the second step "moreToWiderTypesAndLessToWidest" (see code for its definition), indicating that vectors are widened to more elements so they map to natively supported vector widths, or when there isn't a legal wider vector, split the vector to map it to the widest vector supported. Therefore, for the above specification, some example legalizations are: * getAction({G_ADD, LLT::vector(3, 3)}) returns {WidenScalar, LLT::vector(3, 8)} * getAction({G_ADD, LLT::vector(3, 8)}) then returns {MoreElements, LLT::vector(8, 8)} * getAction({G_ADD, LLT::vector(20, 8)}) returns {FewerElements, LLT::vector(16, 8)} 2. Key implementation aspects. How to legalize a specific (operation, type index, size) tuple is represented by mapping intervals of integers representing a range of size types to an action to take, e.g.: setScalarAction({G_ADD, LLT:scalar(1)}, {{1, WidenScalar}, // bit sizes [ 1, 31[ {32, Legal}, // bit sizes [32, 33[ {33, WidenScalar}, // bit sizes [33, 64[ {64, Legal}, // bit sizes [64, 65[ {65, NarrowScalar} // bit sizes [65, +inf[ }); Please note that most of the code to do the actual lowering of non-power-of-2 sized types is currently missing, this is just trying to make it possible for targets to specify what is legal, and how non-legal types should be legalized. Probably quite a bit of further work is needed in the actual legalizing and the other passes in GlobalISel to support non-power-of-2 sized types. I hope the documentation in LegalizerInfo.h and the examples provided in the various {Target}LegalizerInfo.cpp and LegalizerInfoTest.cpp explains well enough how this is meant to be used. This drops the need for LLT::{half,double}...Size(). Differential Revision: https://reviews.llvm.org/D30529 llvm-svn: 317560
* [X86] Don't clobber reserved registers with stack adjustmentsBjorn Steinbrink2017-11-071-0/+26
| | | | | | | | | | | | | | | | | | | | | Summary: Calls using invoke in funclet based functions are assumed to clobber all registers, which causes the stack adjustment using pops to consider all registers not defined by the call to be undefined, which can unfortunately include the base pointer, if one is needed. To prevent this (and possibly other hazards), skip reserved registers when looking for candidate registers. This fixes issue #45034 in the Rust compiler. Reviewers: mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39636 llvm-svn: 317551
* [X86] Add patterns to fold a 64-bit load into the EVEX vcvtph2ps instructions.Craig Topper2017-11-071-12/+4
| | | | llvm-svn: 317548
* [X86] Add patterns for folding a v16i8 with the VEX vcvtph2ps intrinsics.Craig Topper2017-11-071-4/+4
| | | | | | Disable the peephole pass to prove that the pattern is working. llvm-svn: 317547
* [X86] Add a test for a 128-bit vector load feeding a cvtph2ps intrinsic.Craig Topper2017-11-071-0/+26
| | | | | | The instruction only loads 64-bits, but we should be able to fold a wider load and let it be narrowed. llvm-svn: 317546
* [X86] Remove alignment from a load in the f16c intrinsic test. The alignment ↵Craig Topper2017-11-071-1/+1
| | | | | | shouldn't be required for load folding. llvm-svn: 317545
* [X86] Add support for using EVEX instructions for the legacy vcvtph2ps ↵Craig Topper2017-11-071-10/+18
| | | | | | | | intrinsics. Looks like there's some missed load folding opportunities for i64 loads. llvm-svn: 317544
* [X86] Add AVX512VL command line to f16c intrinsic test to show missed EVEX ↵Craig Topper2017-11-071-57/+186
| | | | | | opportunities for the legacy intrinsics. llvm-svn: 317543
* [X86] Use IMPLICIT_DEF in VEX/EVEX vcvtss2sd/vcvtsd2ss patterns instead of a ↵Craig Topper2017-11-071-36/+36
| | | | | | | | COPY_TO_REGCLASS. ExeDepsFix pass should take care of making the registers match. llvm-svn: 317542
* [X86] Make FeatureAVX512 imply FeatureF16C.Craig Topper2017-11-062-1943/+703
| | | | | | | | | | The EVEX to VEX pass is already assuming this is true under AVX512VL. We had special patterns to use zmm instructions if VLX and F16C weren't available. Instead just make AVX512 imply F16C to make the EVEX to VEX behavior explicitly legal and remove the extra patterns. All known CPUs with AVX512 have F16C so this should safe for now. llvm-svn: 317521
* [MIRPrinter] Use %subreg.xxx syntax for subregister index operandsBjorn Pettersson2017-11-0611-80/+80
| | | | | | | | | | | | | | | | | | Summary: Print %subreg.<subregidxname> instead of just the subregister index when printing immediate operands corresponding to subreg indices in INSERT_SUBREG, EXTRACT_SUBREG, SUBREG_TO_REG and REG_SEQUENCE. Reviewers: qcolombet, MatzeB Reviewed By: MatzeB Subscribers: nhaehnle, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D39696 llvm-svn: 317513
* Adds code to PPC ISEL lowering to recognize byte inserts from ↵Graham Yiu2017-11-061-0/+578
| | | | | | | | vector_shuffles, and use P9 shift and vector insert byte instructions instead of vperm. Extends tests from vector insert half-word. Differential Revision: https://reviews.llvm.org/D34497 llvm-svn: 317503
* [PPC] Use xxbrd to speed up bswap64Guozhi Wei2017-11-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Power doesn't have bswap instructions, so llvm generates following code sequence for bswap64. rotldi 5, 3, 16 rotldi 4, 3, 8 rotldi 9, 3, 24 rotldi 10, 3, 32 rotldi 11, 3, 48 rotldi 12, 3, 56 rldimi 4, 5, 8, 48 rldimi 4, 9, 16, 40 rldimi 4, 10, 24, 32 rldimi 4, 11, 40, 16 rldimi 4, 12, 48, 8 rldimi 4, 3, 56, 0 But Power9 has vector bswap instructions, they can also be used to speed up scalar bswap intrinsic. With this patch, bswap64 can be translated to: mtvsrdd 34, 3, 3 xxbrd 34, 34 mfvsrld 3, 34 Differential Revision: https://reviews.llvm.org/D39510 llvm-svn: 317499
* AMDGPU: Select v_mad_u64_u32 and v_mad_i64_i32Matt Arsenault2017-11-062-54/+239
| | | | llvm-svn: 317492
* [AMDGPU] Change alloca addr space of r600 to 5 for amdgiz environmentYaxun Liu2017-11-062-128/+130
| | | | | | Differential Revision: https://reviews.llvm.org/D39657 llvm-svn: 317479
* [AMDGPU] Fix assertion due to assuming pointer in default addr space is 32 bitYaxun Liu2017-11-061-2/+2
| | | | | | | | | | | | The backend assumes pointer in default addr space is 32 bit, which is not true for the new addr space mapping and causes assertion for unresolved functions. This patch fixes that. Differential Revision: https://reviews.llvm.org/D39643 llvm-svn: 317476
* [X86][AVX512] Improve lowering of AVX512 test intrinsicsUriel Korach2017-11-0610-260/+77
| | | | | | | | | | | | Added TESTM and TESTNM to the list of instructions that already zeroing unused upper bits and does not need the redundant shift left and shift right instructions afterwards. Added a pattern for TESTM and TESTNM in iselLowering, so now icmp(neq,and(X,Y), 0) goes folds into TESTM and icmp(eq,and(X,Y), 0) goes folds into TESTNM This commit is a preparation for lowering the test and testn X86 intrinsics to IR. Differential Revision: https://reviews.llvm.org/D38732 llvm-svn: 317465
* X86 ISel: Basic support for variable-index vector permutationsZvi Rackover2017-11-063-1086/+751
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Try to lower a BUILD_VECTOR composed of extract-extract chains that can be reasoned to be a permutation of a vector by indices in a non-constant vector. We saw this pattern created by ISPC, which resolts to creating it due to the requirement that shufflevector's mask operand be a *constant* vector. I didn't check this but we could possibly use this pattern for lowering the X86 permute C-instrinsics instead of llvm.x86 instrinsics. This change can be followed by more improvements: 1. Handle vectors with undef elements. 2. Utilize pshufb and zero-mask-blending to support more effiecient construction of vectors with constant-0 elements. 3. Use smaller-element vectors of same width, and "interpolate" the indices, when no native operation available. Reviewers: RKSimon, craig.topper Reviewed By: RKSimon Subscribers: chandlerc, DavidKreitzer Differential Revision: https://reviews.llvm.org/D39126 llvm-svn: 317463
* [x86][AVX512] Lowering Broadcastm intrinsics to LLVM IRJina Nahias2017-11-067-70/+181
| | | | | | | | | This patch, together with a matching clang patch (https://reviews.llvm.org/D38683), implements the lowering of X86 broadcastm intrinsics to IR. Differential Revision: https://reviews.llvm.org/D38684 Change-Id: I709ac0b34641095397e994c8ff7e15d1315b3540 llvm-svn: 317458
* [X86] Use EVEX encoded intrinsics for legacy FMA intrinsics when possible.Craig Topper2017-11-061-16/+16
| | | | llvm-svn: 317454
* [X86] Add avx512vl command line to fma-instrinsics-x86.llCraig Topper2017-11-061-0/+209
| | | | | | Some of these demonstrate a missed EVEX to VEX compression because we aren't prefering EVEX instructions during isel. llvm-svn: 317452
* [X86] Simplify command lines on the fma-instrinsics-x86.ll test and add ↵Craig Topper2017-11-061-334/+331
| | | | | | | | | | -show-mc-encoding. Use feature names instead of CPU names. A future commit will add avx512vl command lines to demonstrate missed use of EVEX instructions. llvm-svn: 317451
* [X86] Use EVEX encoded instructions for legacy scalar sqrt intrinsics.Craig Topper2017-11-062-9/+19
| | | | | | Fixes PR35161. llvm-svn: 317445
* [X86] Remove some more RCP and RSQRT patterns from InstrAVX512.td that I ↵Craig Topper2017-11-052-12/+12
| | | | | | missed in r317413. llvm-svn: 317441
* [X86][SSE] Tests for integer min/max horizontal reductionsSimon Pilgrim2017-11-054-0/+8204
| | | | | | | | Matching patterns that vectorizers should have created for us. The experimental intrinsics should probably be added as well. llvm-svn: 317439
* [X86][AVX] Regenerate test. NFCI.Simon Pilgrim2017-11-041-7/+0
| | | | llvm-svn: 317424
* [X86] Don't use RCP14 and RSQRT14 for reciprocal estimations or for legacy ↵Craig Topper2017-11-046-56/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SSE rcp/rsqrt intrinsics when AVX512 features are enabled. Summary: AVX512 added RCP14 and RSQRT instructions which improve accuracy over the legacy RCP and RSQRT instruction, but not enough accuracy to remove the need for a Newton Raphson refinement. Currently we use these new instructions for the legacy packed SSE instrinics, but not the scalar instrinsics. And we use it for fast math optimization of division and reciprocal sqrt. I think switching the legacy instrinsics maybe surprising to the user since it changes the answer based on which processor you're using regardless of any fastmath settings. It's also weird that we did something different between scalar and packed. As far at the reciprocal estimation, I think it creates unnecessary deltas in our output behavior (and prevents EVEX->VEX). A little playing around with gcc and icc and godbolt suggest they don't change which instructions they use here. This patch adds new X86ISD nodes for the RCP14/RSQRT14 and uses those for the new intrinsics. Leaving the old intrinsics to use the old instructions. Going forward I think our focus should be on -Supporting 512-bit vectors, which will have to use the RCP14/RSQRT14. -Using RSQRT28/RCP28 to remove the Newton Raphson step on processors with AVX512ER -Supporting double precision. Reviewers: zvi, DavidKreitzer, RKSimon Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D39583 llvm-svn: 317413
* [X86] Regenerate a couple more tests that I missed in r317410.Craig Topper2017-11-042-48/+48
| | | | llvm-svn: 317412
* [X86] Teach EVEX->VEX pass to turn SHUFI32X4/SHUFF32X4/SHUFI64X/SHUFF64X2 ↵Craig Topper2017-11-047-103/+50
| | | | | | | | into VPERM2F128/VPERM2I128. This recovers some of the tests that were changed by r317403. llvm-svn: 317410
* [AMDGPU] Remove hardcoded address space value from AMDGPULibFuncYaxun Liu2017-11-041-61/+61
| | | | | | | | | | | | AMDGPULibFunc hardcodes address space values of the old address space mapping, which causes invalid addrspacecast instructions and undefined functions in APPSDK sample MonteCarloAsianDP. This patch fixes that. Differential Revision: https://reviews.llvm.org/D39616 llvm-svn: 317409
* [X86] Teach shuffle lowering to use 256-bit SHUF128 when possible.Craig Topper2017-11-048-684/+668
| | | | | | | | This allows masked operations to be used and allows the register allocator to use YMM16-31 if necessary. As a follow up I'll look into teaching EVEX->VEX how to turn this back into PERM2X128 if any of the additional features don't work out. llvm-svn: 317403
* [X86] Give unary PERMI priority over SHUF128 in lowerV8I64VectorShuffle to ↵Craig Topper2017-11-031-2/+19
| | | | | | make it possible to fold a load. llvm-svn: 317382
* [AArch64] Fix the number of iterations for the Newton seriesEvandro Menezes2017-11-032-24/+93
| | | | | | | | | The number of iterations was incorrectly determined for DP FP vector types and the tests were insufficient to flag this issue. Differential revision: https://reviews.llvm.org/D39507 llvm-svn: 317349
* [LICM] sink through non-trivially replicable PHIJun Bum Lim2017-11-031-4/+4
| | | | | | | | | | | | | | | | | | | Summary: The current LICM allows sinking an instruction only when it is exposed to exit blocks through a trivially replacable PHI of which all incoming values are the same instruction. This change enhance LICM to sink a sinkable instruction through non-trivially replacable PHIs by spliting predecessors of loop exits. Reviewers: hfinkel, majnemer, davidxl, bmakam, mcrosier, danielcdh, efriedma, jtony Reviewed By: efriedma Subscribers: nemanjai, dberlin, llvm-commits Differential Revision: https://reviews.llvm.org/D37163 llvm-svn: 317335
* [mips] Match 'ins' and its' variants with C++ codeSimon Dardis2017-11-031-5/+9
| | | | | | | | | | | | | Change the ISel matching of 'ins', 'dins[mu]' from tablegen code to C++ code. This resolves an issue where ISel would select 'dins' instead of 'dinsm' when the instructions size and position were individually in range but their sum was out of range according to the ISA specification. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D39117 llvm-svn: 317331
* Fix for Bug 34475 - LOCK/REP/REPNE prefixes emitted as instruction on their own.Andrew V. Tischenko2017-11-031-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D39546 llvm-svn: 317330
* re-land [ExpandMemCmp] Split ExpandMemCmp from CodeGen into its own pass."Clement Courbet2017-11-033-238/+232
| | | | | | Fix undefined references: ExpandMemCmp belongs to CodeGen/, not Scalar/. llvm-svn: 317318
* [X86][SSE] Add PACKUS support to combineVectorTruncationSimon Pilgrim2017-11-033-135/+125
| | | | | | | | Similar to the existing code to lower to PACKSS, we can use PACKUS if the input vector's leading zero bits extend all the way to the packed/truncated value. We have to account for pre-SSE41 targets not supporting PACKUSDW llvm-svn: 317315
* [globalisel][tablegen] Skip src child predicatesDiana Picus2017-11-031-0/+35
| | | | | | | | | | | | | | | | | | The GlobalISel TableGen backend didn't check for predicates on the source children. This caused it to generate code for ARM patterns such as SMLABB or similar, but without properly checking for the sext_16_node part of the operands. This in turn meant that we would select SMLABB instead of MLA for simple sequences such as s32 + s32 * s32, which is wrong (we want a MLA on the full operands, not just their bottom 16 bits). This patch forces TableGen to skip patterns with predicates on the src children, so it doesn't generate code for SMLABB and other similar ARM instructions at all anymore. AArch64 and X86 are not affected. Differential Revision: https://reviews.llvm.org/D39554 llvm-svn: 317313
* [AArch64] Use dwarf exception handling on MinGWMartin Storsjo2017-11-031-0/+36
| | | | | | | | | | Ideally we should probably produce WinEH here as well, but until then, we can use dwarf exceptions, without any further changes required in clang, libunwind or libcxxabi. Differential Revision: https://reviews.llvm.org/D39535 llvm-svn: 317304
* [X86] Remove PALIGNR/VALIGN handling from combineBitcastForMaskedOp and move ↵Craig Topper2017-11-031-2/+2
| | | | | | to isel patterns instead. Prefer 128-bit VALIGND/VALIGNQ over PALIGNR during lowering when possible. llvm-svn: 317299
* Avoid PLT for external calls when attribute nonlazybind is used.Sriraman Tallam2017-11-031-0/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D39065 llvm-svn: 317292
* [Verifier] Remove the -verify-debug-info cl::optVedant Kumar2017-11-021-1/+1
| | | | | | | This cl::opt has been dead for a while. It's no longer possible to run the verifier without also verifying debug info. llvm-svn: 317288
* [AArch64][RegisterBankInfo] Add mapping for G_FPEXT.Quentin Colombet2017-11-021-0/+104
| | | | | | | | | | This fixes http://llvm.org/PR32560. We were missing a description for half floating point type and as a result were using the FPR 32 mapping. Because of the size mismatch the generic code was complaining that the default mapping is not appropriate. Fix the mapping description so that the default mapping can be properly applied. llvm-svn: 317287
* [X86] Give AVX512VL instructions priority over their AVX equivalents.Craig Topper2017-11-023-16/+36
| | | | | | I thought we had gotten all these priority bugs worked out, but I guess not. llvm-svn: 317283
* [Hexagon] Prefer L2_loadrub_io over L4_loadrub_rrKrzysztof Parzyszek2017-11-021-0/+10
| | | | | | | If the offset is an immediate, avoid putting it in a register to get Rs+Rt<<#0. llvm-svn: 317275
* Revert "[ExpandMemCmp] Split ExpandMemCmp from CodeGen into its own pass."Clement Courbet2017-11-023-232/+238
| | | | | | | | | undefined reference to `llvm::TargetPassConfig::ID' on clang-ppc64le-linux-multistage This reverts commit eea333c33fa73ad225ef28607795984829f65688. llvm-svn: 317213
OpenPOWER on IntegriCloud