summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* [mips] Fix the definitions of the EVA instructionsSimon Dardis2018-03-133-75/+84
| | | | | | | | | | Correct their availability to their respective ISAs. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D44209 llvm-svn: 327403
* [SROA] Take advantage of separate alignments for memcpy source and destinationDaniel Neilson2018-03-131-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the SROA pass to cease using the old getAlignment() & setAlignment() APIs of MemoryIntrinsic in favour of getting source & dest specific alignments through the new API. This allows us to enhance visitMemTransferInst to be more aggressive setting the alignment in memcpy calls that it creates, as well as to only change the alignment of a memcpy/memmove argument that it replaces. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278, rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774, rL324781, rL324784, rL324955, rL324960, rL325816 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html Reviewers: chandlerc, bollu, efriedma Reviewed By: efriedma Subscribers: efriedma, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D42974 llvm-svn: 327398
* [CodeView] Omit forward references for unnamed structs and unionsBrock Wyma2018-03-131-10/+40
| | | | | | | | | | Codeview references to unnamed structs and unions are expected to refer to the complete type definition instead of a forward reference so Visual Studio can resolve the type properly. Differential Revision: https://reviews.llvm.org/D32498 llvm-svn: 327397
* [mips] Don't create nested CALLSEQ_START..CALLSEQ_END nodes.Simon Dardis2018-03-131-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the MIPS O32 ABI, the current call lowering logic naively lowers each call, creating the reserved argument area to hold the argument spill areas for $a0..$a3 and the outgoing parameter area if one is required at each call site. In the case of a sufficently large byval argument, a call to memcpy is used to write the start+16..end of the argument into the outgoing parameter area. This is done within the CALLSEQ_START..CALLSEQ_END of the callee. The CALLSEQ nodes are responsible for performing the necessary stack adjustments. Since the O32/N32/N64 MIPS ABIs do not have a red-zone and writing below the stack pointer and reading the values back is unpredictable, the call to memcpy cannot be hoisted out of the callee's CALLSEQ nodes. However, for the O32 ABI requires the reserved argument area for functions which have parameters. The naive lowering of calls will then create nested CALLSEQ sequences. For N32 and N64 these nodes are also created, but with zero stack adjustments as those ABIs do not have a reserved argument area. This patch addresses the correctness issue by recognizing the special case of lowering a byval argument that uses memcpy. By recognizing that the incoming chain already has a CALLSEQ_START node on it when calling memcpy, the CALLSEQ nodes are not created. For the N32 and N64 ABIs, this is not an issue, as no stack adjustment has to be performed. For the O32 ABI, the correctness reasoning is different. In the case of a sufficently large byval argument, registers a0..a3 are going to be used for the callee's arguments, mandating the creation of the reserved argument area. The call to memcpy in the naive case will also create its own reserved argument area. However, since the reserved argument area consists of undefined values, both calls can use the same reserved argument area. Reviewers: abeserminji, atanasyan Differential Revision: https://reviews.llvm.org/D44296 llvm-svn: 327388
* [X86][SSE41] createVariablePermute v2X64 - PCMPEQQ can test for index 0/1 ↵Simon Pilgrim2018-03-131-0/+8
| | | | | | and select between them. llvm-svn: 327385
* [Evaluator] Evaluate load/store with bitcastEugene Leviant2018-03-132-46/+61
| | | | | | Differential revision: https://reviews.llvm.org/D43457 llvm-svn: 327381
* [CodeGenPrepare] Respect endianness in splitMergedValStore.Jonas Paulsson2018-03-131-1/+2
| | | | | | | | | | | | | splitMergedValStore will split a store into two if target prefers this, or if -force-split-store is passed. This patch adds the missing handling for endianness in this function along with a test case. Review: Eli Friedman https://reviews.llvm.org/D44396 llvm-svn: 327375
* [SCEV][NFC] Smarter implementation of isAvailableAtLoopEntryMax Kazantsev2018-03-131-53/+1
| | | | | | | | | | isAvailableAtLoopEntry duplicates logic of `properlyDominates` after checking invariance. This patch replaces this logic with invocation of this method which is more profitable because it supports caching. Differential Revision: https://reviews.llvm.org/D43997 llvm-svn: 327373
* [MergeICmps] Make sure that the comparison only has one use.Clement Courbet2018-03-131-0/+9
| | | | | | | | | | | | Summary: Fixes PR36557. Reviewers: trentxintong, spatel Subscribers: mstorsjo, llvm-commits Differential Revision: https://reviews.llvm.org/D44083 llvm-svn: 327372
* bpf: Enhance debug information for peephole optimization passesYonghong Song2018-03-131-1/+19
| | | | | | | | | | | Add more debug information for peephole optimization passes. These would only be enabled for debug version binary and could help analyzing why some optimization opportunities were missed. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327371
* bpf: New post-RA peephole optimization pass to eliminate bad RA codegenYonghong Song2018-03-133-8/+111
| | | | | | | | | | | | | | | | | This new pass eliminate identical move: MOV rA, rA This is particularly possible to happen when sub-register support enabled. The special type cast insn MOV_32_64 involves different register class on src (i32) and dst (i64), RA could generate useless instruction due to this. This pass also could serve as the bast for further post-RA optimization. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327370
* bpf: Don't expand BSWAP on i32, promote itYonghong Song2018-03-131-1/+1
| | | | | | | | | | | | | | | Currently, there is no ALU32 bswap support in eBPF ISA. BSWAP on i32 was set to EXPAND which would need about eight instructions for single BSWAP. It would be more efficient to promote it to i64, then doing BSWAP on i64. For eBPF programs, most of the promotion are zero extensions which are likely be elimiated later by peephole optimizations. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327369
* bpf: Support subregister definition check on PHI nodeYonghong Song2018-03-131-2/+16
| | | | | | | | | | | | | This patch relax the subregister definition check on Phi node. Previously, we just cancel the optimizatoin when the definition is Phi node while actually we could further check the definitions of incoming parameters of PHI node. This helps catch more elimination opportunities. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327368
* bpf: Extends zero extension elimination beyond comparison instructionsYonghong Song2018-03-131-93/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | The current zero extension elimination was restricted to operands of comparison. It actually could be extended to more cases. For example: int *inc_p (int *p, unsigned a) { return p + a; } 'a' will be promoted to i64 during addition, and the zero extension could be eliminated as well. For the elimination optimization, it should be much better to start recognizing the candidate sequence from the SRL instruction instead of J* instructions. This patch makes it an generic zero extension elimination pass instead of one restricted with comparison. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327367
* bpf: J*_RR should check both operandsYonghong Song2018-03-131-6/+4
| | | | | | | | | | | | | There is a mistake in current code that we "break" out the optimization when the first operand of J*_RR doesn't qualify the elimination. This caused some elimination opportunities missed, for example the one in the testcase. The code should just fall through to handle the second operand. Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327366
* bpf: Tighten subregister definition checkYonghong Song2018-03-131-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current subregister definition check stops after the MOV_32_64 instruction. This means we are thinking all the following instruction sequences are safe to be eliminated: MOV_32_64 rB, wA SLL_ri rB, rB, 32 SRL_ri rB, rB, 32 However, this is *not* true. The source subregister wA of MOV_32_64 could come from a implicit truncation of 64-bit register in which case the high bits of the 64-bit register is not zeroed, therefore we can't eliminate above sequence. For example, for i32_val, we shouldn't do the elimination: long long bar (); int foo (int b, int c) { unsigned int i32_val = (unsigned int) bar(); if (i32_val < 10) return b; else return c; } Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 327365
* Revert [SCEV] Fix isKnownPredicateSerguei Katkov2018-03-131-67/+27
| | | | | | | | It is a revert of rL327362 which causes build bot failures with assert like Assertion `isAvailableAtLoopEntry(RHS, L) && "RHS is not available at Loop Entry"' failed. llvm-svn: 327363
* [SCEV] Fix isKnownPredicateSerguei Katkov2018-03-131-27/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IsKnownPredicate is updated to implement the following algorithm proposed by @sanjoy and @mkazantsev : isKnownPredicate(Pred, LHS, RHS) { Collect set S all loops on which either LHS or RHS depend. If S is non-empty a. Let PD be the element of S which is dominated by all other elements of S b. Let E(LHS) be value of LHS on entry of PD. To get E(LHS), we should just take LHS and replace all AddRecs that are attached to PD on with their entry values. Define E(RHS) in the same way. c. Let B(LHS) be value of L on backedge of PD. To get B(LHS), we should just take LHS and replace all AddRecs that are attached to PD on with their backedge values. Define B(RHS) in the same way. d. Note that E(LHS) and E(RHS) are automatically available on entry of PD, so we can assert on that. e. Return true if isLoopEntryGuardedByCond(Pred, E(LHS), E(RHS)) && isLoopBackedgeGuardedByCond(Pred, B(LHS), B(RHS)) Return true if Pred, L, R is known from ranges, splitting etc. } This is follow-up for https://reviews.llvm.org/D42417. Reviewers: sanjoy, mkazantsev, reames Reviewed By: sanjoy, mkazantsev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43507 llvm-svn: 327362
* Reland r327041: [ThinLTO] Keep available_externally symbols liveVlad Tsyrklevich2018-03-131-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change fixes PR36483. The bug was originally introduced by a change that marked non-prevailing symbols dead. This broke LowerTypeTests handling of available_externally functions, which are non-prevailing. LowerTypeTests uses liveness information to avoid emitting thunks for unused functions. Marking available_externally functions dead is incorrect, the functions are used though the function definitions are not. This change keeps them live, and lets the EliminateAvailableExternally/GlobalDCE passes remove them later instead. (Reland with a suspected fix for a unit test failure I haven't been able to reproduce locally) Reviewers: pcc, tejohnson Reviewed By: tejohnson Subscribers: grimar, mehdi_amini, inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D43690 llvm-svn: 327360
* [LTO] Return proper error object rather than null LTOModuleAdam Nemet2018-03-131-1/+1
| | | | | | | | This caused a crash in LTOModule::createInLocalContext. rdar://37926841 llvm-svn: 327359
* [ThinLTO] Add funtions in callees metadata to CallGraphEdgesTaewook Oh2018-03-131-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If there's a callees metadata attached to the indirect call instruction, add CallGraphEdges to the callees mentioned in the metadata when computing FunctionSummary. * Why this is necessary: Consider following code example: ``` (foo.c) static int f1(int x) {...} static int f2(int x); static int (*fptr)(int) = f2; static int f2(int x) { if (x) fptr=f1; return f1(x); } int foo(int x) { (*fptr)(x); // !callees metadata of !{i32 (i32)* @f1, i32 (i32)* @f2} would be attached to this call. } (bar.c) int bar(int x) { return foo(x); } ``` At LTO time when `foo.o` is imported into `bar.o`, function `foo` might be inlined into `bar` and PGO-guided indirect call promotion will run after that. If the profile data tells that the promotion of `@f1` or `@f2` is beneficial, the optimizer will check if the "promoted" `@f1` or `@f2` (such as `@f1.llvm.0` or `@f2.llvm.0`) is available. Without this patch, importing `!callees` metadata would only add promoted declarations of `@f1` and `@f2` to the `bar.o`, but still the optimizer will assume that the function is available and perform the promotion. The result of that is link failure with `undefined reference to @f1.llvm.0`. This patch fixes this problem by adding callees in the `!callees` metadata to CallGraphEdges so that their definition would be properly imported into. One may ask that there already is a logic to add indirect call promotion targets to be added to CallGraphEdges. However, if profile data says "indirect call promotion is only beneficial under a certain inline context", the logic wouldn't work. In the code example above, if profile data is like ``` bar:1000000:100000 1:100000 1: foo:100000 1: 100000 f1:100000 ``` , Computing FunctionSummary for `foo.o` wouldn't add `foo->f1` to CallGraphEdges. (Also, it is at least "possible" that one can provide profile data to only link step but not to compilation step). Reviewers: tejohnson, mehdi_amini, pcc Reviewed By: tejohnson Subscribers: inglorion, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D44399 llvm-svn: 327358
* [LegalizeTypes] In SplitVecOp_TruncateHelper, use GetSplitVector on the ↵Craig Topper2018-03-131-2/+2
| | | | | | input instead of creating new extract_subvectors. llvm-svn: 327355
* ObjCARC: address review comments from majnemerSaleem Abdulrasool2018-03-121-8/+5
| | | | | | | I forgot to incorporate these comments into the original revision. This is just code cleanup addressing the feedback, NFC. llvm-svn: 327351
* BlockExtractor: Don’t delete functions directlyVolkan Keles2018-03-121-2/+3
| | | | | | | Blocks may have function calls, so don’t erase functions directly to avoid erasing a function that has a user. llvm-svn: 327340
* ObjCARC: teach the cloner about funcletsSaleem Abdulrasool2018-03-121-1/+36
| | | | | | | | | | | | | | In the case that the CallInst that is being moved has an associated operand bundle which is a funclet, the move will construct an invalid instruction. The new site will have a different token and needs to be reassociated with the new instruction. Unfortunately, there is no way to alter the bundle after the construction of the instruction. Replace the call instruction cloning with a custom helper to clone the instruction and reassociate the funclet token. llvm-svn: 327336
* [X86][Btver2] Clean up formatting/comments in scheduler model. NFCI.Simon Pilgrim2018-03-121-11/+18
| | | | | | Moved 'special cases' to be closer to other system classes. llvm-svn: 327332
* Remove the LoopInstSimplify pass (-loop-instsimplify)Vedant Kumar2018-03-125-230/+2
| | | | | | | | | | | | LoopInstSimplify is unused and untested. Reading through the commit history the pass also seems to have a high maintenance burden. It would be best to retire the pass for now. It should be easy to recover if we need something similar in the future. Differential Revision: https://reviews.llvm.org/D44053 llvm-svn: 327329
* Improve caching scheme in ProvenanceAnalysis.Michael Zolotukhin2018-03-122-8/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: ProvenanceAnalysis::related(A, B) currently memoizes its results, and on big tests the cache grows too large, and we're spending most of the time growing/looking through DenseMap. This patch reduces the size of the cache by normalizing keys first: we do that by calling GetUnderlyingObjCPtr on the input values. The results of GetUnderlyingObjCPtr are also memoized in a separate cache. The patch doesn't bring noticable changes to compile time on CTMark, however significantly helps one of our internal tests. Reviewers: gottesmm Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D44270 llvm-svn: 327328
* [PowerPC][NFC] Explicitly state types on FP SDAG patterns in anticipation of ↵Lei Huang2018-03-123-132/+158
| | | | | | adding the f128 type llvm-svn: 327319
* [AArch64] Fold adds with tprel_lo12_nc and secrel_lo12 into a following ldr/strMartin Storsjo2018-03-123-10/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D44355 llvm-svn: 327316
* [InstCombine] Replace calls to getNumUses with hasNUses or hasNUsesOrMoreCraig Topper2018-03-122-5/+5
| | | | | | | | | | getNumUses is a linear time operation. It traverses the user linked list to the end and counts as it goes. Since we are only interested in small constant counts, we should use hasNUses or hasNUsesMore more that terminate the traversal as soon as it can provide the answer. There are still two other locations in InstCombine, but changing those would force a rebase of D44266 which if accepted would remove them. Differential Revision: https://reviews.llvm.org/D44398 llvm-svn: 327315
* [CallSiteSplitting] Use !Instruction::use_empty instead of checking for a ↵Craig Topper2018-03-121-1/+1
| | | | | | | | non-zero return from getNumUses getNumUses is a linear operation. It walks a linked list to get a count. So in this case its better to just ask if there are any users rather than how many. llvm-svn: 327314
* [NFC] Replace iterators in PrintHelp with range-based forJan Korous2018-03-121-6/+4
| | | | llvm-svn: 327312
* [NFC] PrintHelp cleanupJan Korous2018-03-121-3/+1
| | | | llvm-svn: 327311
* [Hexagon] Counting leading/trailing bits is cheapKrzysztof Parzyszek2018-03-121-0/+4
| | | | llvm-svn: 327308
* [X86][Btver2] FSqrt/FDiv reg-reg instructions don't use the AGU.Simon Pilgrim2018-03-121-4/+4
| | | | | | I love you llvm-mca. llvm-svn: 327306
* [SelectionDAG] Improve handling of dangling debug infoBjorn Pettersson2018-03-126-58/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: 1) Make sure to discard dangling debug info if the variable (or variable fragment) is mapped to something new before we had a chance to resolve the dangling debug info. 2) When resolving debug info, make sure to bump the associated SDNodeOrder to ensure that the DBG_VALUE is emitted after the instruction that defines the value used in the DBG_VALUE. This will avoid a debug-use before def scenario as seen in https://bugs.llvm.org/show_bug.cgi?id=36417. The new test case, test/DebugInfo/X86/sdag-dangling-dbgvalue.ll, show some other limitations in how dangling debug info is handled in the SelectionDAG. Since we currently only support having one dangling dbg.value per Value, we will end up dropping debug info when there are more than one variable that is described by the same "dangling value". Reviewers: aprantl Reviewed By: aprantl Subscribers: aprantl, eraman, llvm-commits, JDevlieghere Tags: #debug-info Differential Revision: https://reviews.llvm.org/D44369 llvm-svn: 327303
* [Hexagon] Subtarget feature to emit one instruction per packetKrzysztof Parzyszek2018-03-126-11/+34
| | | | | | | | | | | | | | | | | This adds two features: "packets", and "nvj". Enabling "packets" allows the compiler to generate instruction packets, while disabling it will prevent it and disable all optimizations that generate them. This feature is enabled by default on all subtargets. The feature "nvj" allows the compiler to generate new-value jumps and it implies "packets". It is enabled on all subtargets. The exception is made for packets with endloop instructions, since they require a certain minimum number of instructions in the packets to which they apply. Disabling "packets" will not prevent hardware loops from being generated. llvm-svn: 327302
* [X86] Deleting README-MMX.txt now that all tasks have been completed.Simon Pilgrim2018-03-121-42/+0
| | | | | | MMX buildvectors were improved at rL327247 - new MMX bugs should be raised on bugzilla llvm-svn: 327300
* [AMDGPU][MC][GFX8] Added BUFFER_STORE_LDS_DWORD InstructionDmitry Preobrazhensky2018-03-122-4/+33
| | | | | | | | | See bug 36558: https://bugs.llvm.org/show_bug.cgi?id=36558 Differential Revision: https://reviews.llvm.org/D43950 Reviewers: artem.tamazov, arsenm llvm-svn: 327299
* [X86][Btver2] Prefix all scheduler defs. NFCI.Simon Pilgrim2018-03-121-147/+147
| | | | | | These are all global, so prefix with 'J' to help prevent accidental name clashes with other models. llvm-svn: 327296
* [X86] Remove use of MVT class from the ShuffleDecode library.Craig Topper2018-03-124-277/+240
| | | | | | | | MVT belongs to the CodeGen layer, but ShuffleDecode is used by the X86 InstPrinter which is part of the MC layer. This only worked because MVT is completely implemented in a header file with no other library dependencies. Differential Revision: https://reviews.llvm.org/D44353 llvm-svn: 327292
* [AMDGPU] Fix lowering enqueue kernel when kernel has no nameYaxun Liu2018-03-121-8/+16
| | | | | | | | | | Since the enqueued kernels have internal linkage, their names may be dropped. In this case, give them unique names __amdgpu_enqueued_kernel or __amdgpu_enqueued_kernel.n where n is a sequential number starting from 1. Differential Revision: https://reviews.llvm.org/D44322 llvm-svn: 327291
* [X86][Btver2] Extend JWriteResFpuPair to accept resource/uop counts. NFCI.Simon Pilgrim2018-03-121-51/+24
| | | | | | This allows the single resource classes (VarBlend, MPSAD, VarVecShift) to use the JWriteResFpuPair macro. llvm-svn: 327289
* [X86][Btver2] Use JWriteResFpuPair wrapper for AES/CLMUL/HADD scheduler ↵Simon Pilgrim2018-03-121-49/+6
| | | | | | | | cases. NFCI. These are single pipe and have the default resource/uop counts like JWriteResFpuPair so there's no need to handle them separately. llvm-svn: 327283
* [AMDGPU][MC] Corrected GATHER4 opcodesDmitry Preobrazhensky2018-03-123-82/+119
| | | | | | | | | See bug 36252: https://bugs.llvm.org/show_bug.cgi?id=36252 Differential Revision: https://reviews.llvm.org/D43874 Reviewers: artem.tamazov, arsenm llvm-svn: 327278
* [DebugInfo] Replace unreachable with NoneJonas Devlieghere2018-03-121-1/+1
| | | | | | | | | Invalid user input should not trigger assertions and unreachables. We already return an Option so we should just return None here. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5532 llvm-svn: 327274
* [Hexagon] fix 'must explicitly initialize the const member' error which ↵Sam McCall2018-03-121-2/+2
| | | | | | clang 3.8 emits llvm-svn: 327273
* AMDGPU/GlobalISel: Legality and RegBankInfo for G_{INSERT|EXTRACT}_VECTOR_ELTMatt Arsenault2018-03-122-0/+70
| | | | llvm-svn: 327269
* AMDGPU/GlobalISel: InstrMapping for G_MERGE_VALUESMatt Arsenault2018-03-121-0/+12
| | | | llvm-svn: 327268
OpenPOWER on IntegriCloud