summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Revert r250342.Akira Hatanaka2015-10-143-50/+4
| | | | | | Investigate why coal-sections-powerpc.s is failing on some buildbots. llvm-svn: 250346
* [MachO] Stop generating *coal* sections.Akira Hatanaka2015-10-143-4/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some background on why we don't have to use *coal* sections anymore: Long ago when C++ was new and "weak" had not been standardized, an attempt was made in cctools to support C++ inlines that can be coalesced by putting them into their own section (TEXT/textcoal_nt instead of TEXT/text). The current macho linker supports the weak-def bit on any symbol to allow it to be coalesced, but the compiler still puts weak-def functions/data into alternate section names, which the linker must map back to the base section name. This patch makes changes that are necessary to prevent the compiler from using the "coal" sections and have it use the non-coal sections instead when the target architecture is not powerpc: TEXT/textcoal_nt instead use TEXT/text TEXT/const_coal instead use TEXT/const DATA/datacoal_nt instead use DATA/data If the target is powerpc, we continue to use the *coal* sections since anyone targeting powerpc is probably using an old linker that doesn't have support for the weak-def bits. Also, have the assembler issue a warning if it encounters a *coal* section in the assembly file and inform the users to use the non-coal sections instead. rdar://problem/14265330 Differential Revision: http://reviews.llvm.org/D13188 llvm-svn: 250342
* add x86 codegen tests for 'add nsw' followed by 'sext'Sanjay Patel2015-10-141-0/+179
| | | | llvm-svn: 250332
* [PowerPC] Fix invalid lxvdsx optimization (PR25157)Bill Schmidt2015-10-141-0/+58
| | | | | | | | | | | | PR25157 identifies a bug where a load plus a vector shuffle is incorrectly converted into an LXVDSX instruction. That optimization is only valid if the load is of a doubleword, and in the noted case, it was not. This corrects that problem. Joint patch with Eric Schweitz, who provided the bugpoint-reduced test case. llvm-svn: 250324
* [x86][FastISel] Teach how to select nontemporal stores.Andrea Di Biagio2015-10-141-0/+69
| | | | | | | | | | | | | | | | | | | | | | This patch teaches x86 fast-isel how to select nontemporal stores. On x86, we can use MOVNTI for nontemporal stores of doublewords/quadwords. Instructions (V)MOVNTPS/PD/DQ can be used for SSE2/AVX aligned nontemporal vector stores. Before this patch, fast-isel always selected 'movd/movq' instead of 'movnti' for doubleword/quadword nontemporal stores. In the case of nontemporal stores of aligned vectors, fast-isel always selected movaps/movapd/movdqa instead of movntps/movntpd/movntdq. With this patch, if we use SSE2/AVX intrinsics for nontemporal stores we now always get the expected (V)MOVNT instructions. The lack of fast-isel support for nontemporal stores was spotted when analyzing the -O0 codegen for nontemporal stores. Differential Revision: http://reviews.llvm.org/D13698 llvm-svn: 250285
* [WinEH] Add CoreCLR EH table emissionJoseph Tremoulet2015-10-131-0/+239
| | | | | | | | | | | | | | | | | | Summary: Emit the handler and clause locations immediately after the standard xdata. Clauses are emitted in the same order and format used to communiate them to the CLR Execution Engine. Add a lit test to verify correct table generation on a small but interesting example function. Reviewers: majnemer, andrew.w.kaylor, rnk Subscribers: pgavlin, AndyAyers, llvm-commits Differential Revision: http://reviews.llvm.org/D13451 llvm-svn: 250219
* DAGCombiner: Don't stop finding better chain on 2 aliasesMatt Arsenault2015-10-131-22/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | The comment says this was stopped because it was unlikely to be profitable. This is not true if you want to combine vector loads with multiple components. For a simple case that looks like t0 = load t0 ... t1 = load t0 ... t2 = load t0 ... t3 = load t0 ... t4 = store t0:1, t0:1 t5 = store t4, t1:0 t6 = store t5, t2:0 t7 = store t6, t3:0 We want to get all of these stores onto a chain that is a TokenFactor of these N loads. This mostly solves the AMDGPU merge-stores.ll regressions with -combiner-alias-analysis for merging vector stores of vector loads. llvm-svn: 250138
* x86: preserve flags when folding atomic operationsJF Bastien2015-10-131-0/+38
| | | | | | | | | | | | | | | | | | | | | Summary: D4796 taught LLVM to fold some atomic integer operations into a single instruction. The pattern was unaware that the instructions clobbered flags. This patch adds the missing EFLAGS definition. Floating point operations don't set flags, the subsequent fadd optimization is therefore correct. The same applies for surrounding load/store optimizations. Reviewers: rsmith, rtrieu Subscribers: llvm-commits, reames, morisset Differential Revision: http://reviews.llvm.org/D13680 llvm-svn: 250135
* DAGCombiner: Combine extract_vector_elt from build_vectorMatt Arsenault2015-10-125-28/+39
| | | | | | | | | | | | | | This basic combine was surprisingly missing. AMDGPU legalizes many operations in terms of 32-bit vector components, so not doing this results in many extra copies and subregister extracts that need to be cleaned up later. InstCombine already does this for the hasOneUse case. The target hook is to fix a handful of tests which break (e.g. ARM/vmov.ll) which turn from a vector materialize repeated immediate instruction to a constant vector load with more scalar copies from it. llvm-svn: 250129
* Assign correct edge weights to unwind destinations when lowering invoke ↵Cong Hou2015-10-124-9/+94
| | | | | | | | | | statement. When lowering invoke statement, all unwind destinations are directly added as successors of call site block, and the weight of those new edges are not assigned properly. Actually, default weight 16 are used for those edges. This patch calculates the proper edge weights for those edges when collecting all unwind destinations. Differential revision: http://reviews.llvm.org/D13354 llvm-svn: 250119
* Make Win64 localescape offsets FP relative instead of SP relativeReid Kleckner2015-10-121-18/+33
| | | | | | | | | We made them SP relative back in March (r233137) because that's the value the runtime passes to EH functions. With the new cleanuppad IR, funclets adjust their frame argument from SP to FP, so our offsets should now be FP-relative. llvm-svn: 250088
* [x86] Fix wrong lowering of vsetcc nodes (PR25080).Andrea Di Biagio2015-10-121-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong assumption that for non-AVX512 targets, the source type and destination type of a type-legalized setcc node were always the same type. This assumption was unfortunately incorrect; the type legalizer is not always able to promote the return type of a setcc to the same type as the first operand of a setcc. In the case of a vsetcc node, the legalizer firstly checks if the first input operand has a legal type. If so, then it promotes the return type of the vsetcc to that same type. Otherwise, the return type is promoted to the 'next legal type', which, for vectors of MVT::i1 is always a 128-bit integer vector type. Example (-mattr=+avx): %0 = trunc <8 x i32> %a to <8 x i23> %1 = icmp eq <8 x i23> %0, zeroinitializer The initial selection dag for the code above is: v8i1 = setcc t5, t7, seteq:ch t5: v8i23 = truncate t2 t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1 t7: v8i32 = build_vector of all zeroes. The type legalizer would firstly check if 't5' has a legal type. If so, then it would reuse that same type to promote the return type of the setcc node. Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to promote the return type of the setcc node. Consequently, the setcc return type is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the following dag node: v8i16 = setcc t32, t25, seteq:ch where t32 and t25 are now values of type v8i32. Before this patch, function LowerVSETCC would have wrongly expanded the setcc to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an instruction. In our case, ISel would have matched a VPCMPEQWrr: t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25 However, t36 and t25 are both VR256, while the result type is instead of class VR128. This inconsistency ended up causing the insertion of COPY instructions like this: %vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3 Which is an invalid full copy (not a sub register copy). Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy instruction" in the attempt to expand the malformed pseudo COPY instructions. This patch fixes the problem adding the missing logic in LowerVSETCC to handle the corner case of a setcc with 128-bit return type and 256-bit operand type. This problem was originally reported by Dimitry as PR25080. It has been latent for a very long time. I have added the minimal reproducible from that bugzilla as test setcc-lowering.ll. Differential Revision: http://reviews.llvm.org/D13660 llvm-svn: 250085
* [AArch64]Fix bug in function names in test caseJun Bum Lim2015-10-121-4/+4
| | | | | | | Functions in this test case need to be renamed as its names are the same as the instructions we are comparing with. llvm-svn: 250052
* [mips] Whitespace cleanup in MIPS16 tests to reduce noise in following ↵Daniel Sanders2015-10-123-267/+267
| | | | | | | | changes. NFC. Mostly tabs -> spaces and double spacing. llvm-svn: 250041
* [mips] Handle undef when extracting subregs from FP64 registers.Daniel Sanders2015-10-121-0/+14
| | | | | | | | | | | | | | | Summary: This removes unnecessary instructions when extracting from an undefined register and also fixes a crash for O32 when passing undef to a double argument in held in integer registers. Reviewers: vkalintiris Subscribers: llvm-commits, zoran.jovanovic, petarj Differential Revision: http://reviews.llvm.org/D13467 llvm-svn: 250039
* [X86] Add XSAVE intrinsic familyAmjad Aboud2015-10-128-0/+194
| | | | | | | | | | | | Add intrinsics for the XSAVE instructions (XSAVE/XSAVE64/XRSTOR/XRSTOR64) XSAVEOPT instructions (XSAVEOPT/XSAVEOPT64) XSAVEC instructions (XSAVEC/XSAVEC64) XSAVES instructions (XSAVES/XSAVES64/XRSTORS/XRSTORS64) Differential Revision: http://reviews.llvm.org/D13012 llvm-svn: 250029
* [x86] PR24562: fix incorrect folding of PSHUFB nodes with a mask where all ↵Andrea Di Biagio2015-10-121-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | indices have the most significant bit set. This patch fixes a problem in function 'combineX86ShuffleChain' that causes a chain of shuffles to be wrongly folded away when the combined shuffle mask has only one element. We may end up with a combined shuffle mask of one element as a result of multiple calls to function 'canWidenShuffleElements()'. Function canWidenShuffleElements attempts to simplify a shuffle mask by widening the size of the elements being shuffled. For every pair of shuffle indices, function canWidenShuffleElements checks if indices refer to adjacent elements. If all pairs refer to "adjacent" elements then the shuffle mask is safely widened. As a consequence of widening, we end up with a new shuffle mask which is half the size of the original shuffle mask. The byte shuffle (pshufb) from test pr24562.ll has a mask of all SM_SentinelZero indices. Function canWidenShuffleElements would combine each pair of SM_SentinelZero indices into a single SM_SentinelZero index. So, in a logarithmic number of steps (4 in this case), the pshufb mask is simplified to a mask with only one index which is equal to SM_SentinelZero. Before this patch, function combineX86ShuffleChain wrongly assumed that a mask of size one is always equivalent to an identity mask. So, the entire shuffle chain was just folded away as the combined shuffle mask was treated as a no-op mask. With this patch we know check if the only element of a combined shuffle mask is SM_SentinelZero. In case, we propagate a zero vector. Differential Revision: http://reviews.llvm.org/D13364 llvm-svn: 250027
* [DAGCombiner] Improved FMA combine support for vectorsSimon Pilgrim2015-10-111-151/+185
| | | | | | | | Enabled constant canonicalization for all constants. Improved combining of constant vectors. llvm-svn: 249993
* [X86] Remove special validation for INT immediate operand from AsmParser. ↵Craig Topper2015-10-111-1/+1
| | | | | | | | Instead mark its operand type as u8imm which will cause it to fail to match. This is more consistent with other instruction behavior. This also fixes a bug where negative immediates below -128 were not being reported as errors. llvm-svn: 249989
* [X86][XOP] Added support for the lowering of 128-bit vector integer ↵Simon Pilgrim2015-10-112-142/+54
| | | | | | | | comparisons to XOP PCOM/PCOMU instructions. The XOP vector integer comparisons can deal with all signed/unsigned comparison cases directly and can be easily commuted as well (D7646). llvm-svn: 249976
* [X86][SSE] Vector signed/unsigned integer compare tests.Simon Pilgrim2015-10-102-0/+1668
| | | | llvm-svn: 249954
* [SystemZ] CodeGen/SystemZ/asm-18.ll run with -verify-machineinstrsJonas Paulsson2015-10-101-1/+2
| | | | | | Relates to the fixes of r249811. llvm-svn: 249946
* [SystemZ] Fixes in the backend I/R.Jonas Paulsson2015-10-101-1/+2
| | | | | | | | | | | | | | | expandPostRAPseudo(): STX -> 2 * STD: The first STD should not have the kill flag set for the address. SystemZElimCompare: BRC -> BRCT conversion: Don't forget to remove the CC<use,kill> operand. Needed to make SystemZ/asm-17.ll pass with -verify-machineinstrs, which now runs with this flag. Reviewed by Ulrich Weigand. llvm-svn: 249945
* [WinEH] Delete the old landingpad implementation of Windows EHReid Kleckner2015-10-0928-4620/+0
| | | | | | | | | | | The new implementation works at least as well as the old implementation did. Also delete the associated preparation tests. They don't exercise interesting corner cases of the new implementation. All the codegen tests of the EH tables have already been ported. llvm-svn: 249918
* [SEH] Update SEH codegen tests to use the new IRReid Kleckner2015-10-0910-317/+150
| | | | | | | | | Also Fix a buglet where SEH tables had ranges that spanned funclets. The remaining tests using the old landingpad IR are preparation tests, and will be deleted along with the old preparation. llvm-svn: 249917
* [WinEH] Insert the catchpad return before CSR restorationDavid Majnemer2015-10-091-0/+3
| | | | | | | | x64 catchpads use rax to inform the unwinder where control should go next. However, we must initialize rax before the epilogue sequence so as to not perturb the unwinder. llvm-svn: 249910
* Fix assert when emitting llvm.pow.f86.James Y Knight2015-10-091-0/+41
| | | | | | | | | | | | | This occurred due to introducing the invalid i64 type after type legalization had already finished, in an attempt to workaround bitcast f64 -> v2i32 not doing constant folding. The *right* thing is to actually fix bitcast, but that has other complications. So, for now, just get rid of the broken workaround, and check in a test-case showing that it doesn't crash, with TODOs for emitting proper code. llvm-svn: 249908
* [SEH] Fix _except_handler4 table base statesReid Kleckner2015-10-091-22/+20
| | | | | | | We got them right for the old IR, but not with funclets. Port the old test to the new IR and fix the code. llvm-svn: 249906
* [SEH] Remember to emit the last invoke range for SEHReid Kleckner2015-10-092-22/+26
| | | | | | | | This wasn't very observable in execution tests, because usually there is an invoke in the catchpad that unwinds the the catchendpad but never actually throws. llvm-svn: 249898
* Fix assert in X86 backend.James Y Knight2015-10-091-0/+6
| | | | | | | | | | | | | | When running combine on an extract_vector_elt, it wants to look through a bitcast to check if the argument to the bitcast was itself an extract_vector_elt with particular operands. However, it called getOperand() on the argument to the bitcast *before* checking that the opcode was EXTRACT_VECTOR_ELT, assert-failing if there were zero operands for the actual opcode. Fix, and add trivial test. llvm-svn: 249891
* [WebAssembly] Rename floating-point operators to match their spec names.Dan Gohman2015-10-092-12/+12
| | | | llvm-svn: 249859
* Improve ISel across lane float min/max reductionJun Bum Lim2015-10-091-0/+32
| | | | | | | | | | | | | | | | | | | | In vectorized float min/max reduction code, the final "reduce" step is sub-optimal. In AArch64, this change wll combine : svn0 = vector_shuffle t0, undef<2,3,u,u> fmin = fminnum t0,svn0 svn1 = vector_shuffle fmin, undef<1,u,u,u> cc = setcc fmin, svn1, ole n0 = extract_vector_elt cc, #0 n1 = extract_vector_elt fmin, #0 n2 = extract_vector_elt fmin, #1 result = select n0, n1,n2 into : result = llvm.aarch64.neon.fminnmv t0 This change extends r247575. llvm-svn: 249834
* Vector element extraction without stack operations on Power 8Nemanja Ivanovic2015-10-091-0/+1380
| | | | | | | | | | | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D12032 This patch builds onto the patch that provided scalar to vector conversions without stack operations (D11471). Included in this patch: - Vector element extraction for all vector types with constant element number - Vector element extraction for v16i8 and v8i16 with variable element number - Removal of some unnecessary COPY_TO_REGCLASS operations that ended up unnecessarily moving things around between registers Not included in this patch (will be in upcoming patch): - Vector element extraction for v4i32, v4f32, v2i64 and v2f64 with variable element number - Vector element insertion for variable/constant element number Testing is provided for all extractions. The extractions that are not implemented yet are just placeholders. llvm-svn: 249822
* ARM: tweak WoA frame loweringSaleem Abdulrasool2015-10-091-0/+22
| | | | | | | | | | Accept r11 when targeting Windows on ARM rather than just low registers. Because we are in a thumb-2 only mode, this may be slightly more expensive in code size, but results in better code for the environment since it spills the frame register, which is generally desired for fast stack walking as per the ABI. llvm-svn: 249804
* Revert "Revert "Revert r248959, "[WinEH] Emit int3 after noreturn calls on ↵Reid Kleckner2015-10-093-107/+4
| | | | | | | | | | Win64""" This reverts commit r249794. Apparently my checkouts are full of unexpected surprises today. llvm-svn: 249796
* Revert "Revert r248959, "[WinEH] Emit int3 after noreturn calls on Win64""Reid Kleckner2015-10-093-4/+107
| | | | | | | | This reverts commit r249032. TODO write commit msg llvm-svn: 249794
* [WinEH] Fix cleanup state numberingJoseph Tremoulet2015-10-091-0/+100
| | | | | | | | | | | | | | | | | | | Summary: - Recurse from cleanupendpads to their cleanuppads, to make sure the cleanuppad is visited if it has a cleanupendpad but no cleanupret. - Check for and avoid double-processing cleanuppads, to allow for them to have multiple cleanuprets (plus cleanupendpads). - Update Cxx state numbering to visit toplevel cleanupendpads and to recurse from cleanupendpads to their preds, to ensure we number any funclets in inlined cleanups. SEH state numbering already did this. Reviewers: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13374 llvm-svn: 249792
* [SEH] Fix llvm.eh.exceptioncode fast register allocation assertionReid Kleckner2015-10-091-2/+2
| | | | | | I called the wrong MachineBasicBlock::addLiveIn() overload. llvm-svn: 249786
* Remove a '#' so that we can check either form for the various targets.Eric Christopher2015-10-081-1/+1
| | | | llvm-svn: 249734
* Move the MMX subtarget feature out of the SSE set of features and intoEric Christopher2015-10-084-3/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | its own variable. This is needed so that we can explicitly turn off MMX without turning off SSE and also so that we can diagnose feature set incompatibilities that involve MMX without SSE. Rationale: // sse3 __m128d test_mm_addsub_pd(__m128d A, __m128d B) { return _mm_addsub_pd(A, B); } // mmx void shift(__m64 a, __m64 b, int c) { _mm_slli_pi16(a, c); _mm_slli_pi32(a, c); _mm_slli_si64(a, c); _mm_srli_pi16(a, c); _mm_srli_pi32(a, c); _mm_srli_si64(a, c); _mm_srai_pi16(a, c); _mm_srai_pi32(a, c); } clang -msse3 -mno-mmx file.c -c For this code we should be able to explicitly turn off MMX without affecting the compilation of the SSE3 function and then diagnose and error on compiling the MMX function. This matches the existing gcc behavior and follows the spirit of the SSE/MMX separation in llvm where we can (and do) turn off MMX code generation except in the presence of intrinsics. Updated a couple of tests, but primarily tested with a couple of tests for turning on only mmx and only sse. This is paired with a patch to clang to take advantage of this behavior. llvm-svn: 249731
* [bpf] Do not expand UNDEF SDNode during insn selection loweringAlexei Starovoitov2015-10-082-1/+69
| | | | | | | | | | | | | | | | | | o Before this patch, BPF backend will expand UNDEF node to i64 constant 0. o For second pass of dag combiner, legalizer will run through each to-be-processed dag node. o If any new SDNode is generated and has an undef operand, dag combiner will put undef node, newly-generated constant-0 node, and any node which uses these nodes in the working list. o During this process, it is possible undef operand is generated again, and this will form an infinite loop for dag combiner pass2. o This patch allows UNDEF to be a legal type. Signed-off-by: Yonghong Song <yhs@plumgrid.com> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> llvm-svn: 249718
* [WinEH] Relax assertion in the presence of stack realignmentReid Kleckner2015-10-081-0/+80
| | | | | | The code is correct as is, but we should test it. llvm-svn: 249715
* [SystemZ] Fix another assertion failure in tryBuildVectorShuffleUlrich Weigand2015-10-081-0/+38
| | | | | | | | | | | | | | | | This fixes yet another scenario where tryBuildVectorShuffle would attempt to create a BUILD_VECTOR node with an invalid combination of types. This can happen if the incoming BUILD_VECTOR has elements of a type different from the vector element type, which is allowed in certain cases as long as they are all the same type. When one of these elements is used in the residual vector, and UNDEF elements are added to fill up the residual vector, those UNDEFs then have to use the type of the original element, not the vector element type, or else the resulting BUILD_VECTOR will have an invalid type combination. llvm-svn: 249706
* [X86] Disable X86CallFrameOptimization on Darwin in presence of EHFrederic Riss2015-10-081-0/+5
| | | | | | | | | | | | | | We emit 1 compact unwind encoding per function, and this can’t represent the varying stack pointer that will be generated by X86CallFrameOptimization. Disable the optimization on Darwin. (It might be possible to split the function into multiple ranges and emit 1 compact unwind info per range. The compact unwind emission code isn’t ready for that and this kind of info certainly isn’t tested/used anywhere. It might be worth exploring this path if we want to get the space savings at some point though) llvm-svn: 249694
* AVX512: vpextrb/w/d/q and vpinsrb/w/d/q implementation.Igor Breger2015-10-083-0/+485
| | | | | | | | | This instructions doesn't have intrincis. Added tests for lowering and encoding. Differential Revision: http://reviews.llvm.org/D12317 llvm-svn: 249688
* [X86] Fix wrong treatment of multi-lane blends in BUILD_VECTORtoBlendMask()Michael Kuperstein2015-10-081-34/+38
| | | | | | | | | | | This fixes two separate bugs: 1) The mask for the high lane was not set correctly. That fixes PR24532. 2) The transformation should bail out if it believes it involves more than 2 lanes, as it does not currently do anything sensible in this case. Differential Revision: http://reviews.llvm.org/D13505 llvm-svn: 249669
* Do not assert on first non-prologue instruction being a CFI directive.Michael Kuperstein2015-10-081-0/+58
| | | | llvm-svn: 249668
* [SystemZ] SystemZElimCompare pass improved.Jonas Paulsson2015-10-081-13/+14
| | | | | | | | | | | | | | Compare elimination extended to recognize load-and-test instructions used for comparison and eliminate them the same way as with compare instructions. Test case fp-cmp-05.ll updated to expect optimized results now also for z13. The order of instruction shortening and compare elimination passes have been changed so that opcodes do not have to be handled in both passes. Reviewed by Ulrich Weigand. llvm-svn: 249666
* [SystemZ] Use load-and-test for fp compare with 0 if vector support is present.Jonas Paulsson2015-10-081-2/+1
| | | | | | | | | Since the LTxBRCompare instructions can't be used with vector registers, a normal load-and-test instruction (with a modelled def operand) is used instead. Reviewed by Ulrich Weigand. llvm-svn: 249664
* [WinEH] Add missing test case for llvm.eh.exceptioncodeReid Kleckner2015-10-071-0/+41
| | | | llvm-svn: 249638
OpenPOWER on IntegriCloud