summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [InstCombine] Teach SimplifyDemandedBits that udiv doesn't demand low ↵Benjamin Kramer2018-05-091-0/+16
| | | | | | | | | | | dividend bits that are zero in the divisor This is safe as long as the udiv is not exact. The pattern is not common in C++ code, but comes up all the time in code generated by XLA's GPU backend. Differential Revision: https://reviews.llvm.org/D46647 llvm-svn: 331933
* [ARM] Add support for SETCCCARRY instead of SETCCEAmaury Sechet2018-05-091-5/+12
| | | | | | | | | | | | Summary: As per title. SETCCE is deprecated and will eventually be removed. Reviewers: rogfer01, efriedma, rengolin, javed.absar Subscribers: kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D46512 llvm-svn: 331929
* [GlobalISel][Legalizer] Widening the second src op of shifts bug fixRoman Tereshin2018-05-091-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | The second source operand of G_SHL, G_ASHR, and G_LSHR must preserve its value as a (small) unsigned integer, therefore its incorrect to widen it in any way but by zero extending it. G_SHL was using G_ANYEXT and G_ASHR - G_SEXT (which is correct for their destination and first source operands, but not the "number of bits to shift" operand). Generally, shifts aren't as similar to regular binary operations as it might seem, for instance, they aren't commutative nor associative and the second source operand usually requires a special treatment. Reviewers: bogner, javed.absar, aivchenk, rovka Reviewed By: bogner Subscribers: igorb, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46413 llvm-svn: 331926
* [AMDGPU] Support horizontal vectorization of min/max.Farhana Aleen2018-05-093-1/+26
| | | | | | | | | | | | Author: FarhanaAleen Reviewed By: rampitec Subscribers: AMDGPU Differential Revision: https://reviews.llvm.org/D46604 llvm-svn: 331920
* AMDGPU: Ignore any_extend in mul24 combineMatt Arsenault2018-05-091-0/+11
| | | | | | | | | | If a multiply is truncated, SimplifyDemandedBits sometimes turns a zero_extend of the inputs into an any_extend, which makes the known bits computation unhelpful. Ignore these and compute known bits for the underlying value, since we insert the correct extend type after. llvm-svn: 331919
* [Hexagon] Add patterns for vector shift-and-accumulateKrzysztof Parzyszek2018-05-091-0/+5
| | | | llvm-svn: 331918
* AMDGPU: Handle partial shift reduction for variable shiftsMatt Arsenault2018-05-091-15/+22
| | | | | | | If the variable shift amount has known bits, we can still reduce the shift. llvm-svn: 331917
* AMDGPU: Partially shrink 64-bit shifts if reduced to 16-bitMatt Arsenault2018-05-091-0/+30
| | | | | | | | | This is an extension of an existing combine to reduce wider shls if the result fits in the final result type. This introduces the same combine, but reduces the shift to a middle sized type to avoid the slow 64-bit shift. llvm-svn: 331916
* [X86] Fix Broadwell's Shuffle256 schedule classes load latency values.Simon Pilgrim2018-05-091-21/+4
| | | | | | Allows us to remove some unnecessary InstRW overrides. llvm-svn: 331913
* [X86] Merge instregex patterns to reduce InstrRW compile time.Simon Pilgrim2018-05-095-1052/+365
| | | | llvm-svn: 331911
* AMDGPU: Add combine for trunc of bitcast from build_vectorMatt Arsenault2018-05-092-0/+31
| | | | | | | | | | | | If the truncate is only accessing the first element of the vector, we can use the original source value. This helps with some combine ordering issues after operations are lowered to integer operations between bitcasts of build_vector. In particular it stops unnecessarily materializing the unused top half of a vector in some cases. llvm-svn: 331909
* [Hexagon] Check the end of the correct container (fix typo)Krzysztof Parzyszek2018-05-091-3/+1
| | | | llvm-svn: 331907
* AMDGPU: Stop special casing constant indexes of extract_vector_eltMatt Arsenault2018-05-091-15/+0
| | | | | | | The same result folds out of the dynamic expansion logic if the index is constant. llvm-svn: 331906
* Reapplying r331819 [GlobalISel][Legalizer] More concise and faster ↵Roman Tereshin2018-05-092-236/+144
| | | | | | | | | widenScalar, NFC The commit was a suspect for clang-cmake-aarch64-global-isel and clang-cmake-aarch64-quick bot failures, proved to be innocent. llvm-svn: 331898
* [DAGCombiner] In visitBITCAST when trying to constant fold the bitcast, only ↵Craig Topper2018-05-091-11/+11
| | | | | | | | | | call getBitcast if its an fp->int or int->fp conversion even when before legalize ops. Previously if !LegalOperations we would blindly call getBitcast and hope that getNode would constant fold it. But if the conversion is between a vector and a scalar, getNode has no simplification. This means we would just get back the original N. We would then return that N which would make the caller of visitBITCAST think that we used CombineTo and did our own worklist management. This prevents target specific optimizations from being called for vector/scalar bitcasts until after legal operations. llvm-svn: 331896
* [InstCombine] snprintf optimizationsDavid Bolvansky2018-05-091-0/+90
| | | | | | | | | | | | Reviewers: spatel, efriedma, majnemer, rja, bkramer Reviewed By: rja, bkramer Subscribers: rja, llvm-commits Differential Revision: https://reviews.llvm.org/D46285 llvm-svn: 331889
* [DAGCombine] Change store merge candidates check cut off to 1024.Amara Emerson2018-05-091-1/+1
| | | | | | | | | | | The previous value of 8192 resulted in severe compile time hits in some pathological cases. rdar://39781410 Differential Revision: https://reviews.llvm.org/D46581 llvm-svn: 331888
* [Hexagon] Fix sanitizer error about using -1u in variable of enum typeKrzysztof Parzyszek2018-05-091-4/+4
| | | | llvm-svn: 331887
* [LV] Change MaxVectorSize bound to 256 in assertion, NFC otherwiseKrzysztof Parzyszek2018-05-091-2/+2
| | | | | | | It's possible to have a vector of 256 bytes in HVX code on Hexagon (vector pair in 128-byte mode). llvm-svn: 331885
* APFloat/x87: Fix string conversion for "unnormal" values (pr35860)Pavel Labath2018-05-091-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Unnormal values are a feature of some very old x87 processors. We handle them correctly for the most part -- the only exception was an unnormal value whose significand happened to be zero. In this case the APFloat was still initialized as normal number (category = fcNormal), but a subsequent toString operation would assert because the math would produce nonsensical values for the zero significand. During review, it was decided that the correct way to fix this is to treat all unnormal values as NaNs (as that is what any >=386 processor will do). The issue was discovered because LLDB would crash when trying to print some "long double" values. Reviewers: skatkov, scanon, gottesmm Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41868 llvm-svn: 331884
* [Hexagon] Simplify MCCodeEmitter, move data to tablesKrzysztof Parzyszek2018-05-092-588/+567
| | | | llvm-svn: 331883
* [Support/Path] Make handling of paths like "///" consistentPavel Labath2018-05-091-24/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Various path functions were not treating paths consisting of slashes alone consistently. For example, the iterator-based accessors decomposed the path "///" into two elements: "/" and ".". This is not too bad, but it is different from the behavior specified by posix: ``` A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname. ``` More importantly, this was different from how we treated the same path in the filename+parent_path functions, which decomposed this path into "." and "". This was completely wrong as it lost the information that this was an absolute path which referred to the root directory. This patch fixes this behavior by making sure all functions treat paths consisting of (back)slashes alone the same way as "/". I.e., the iterator-based functions will just report one component ("/"), and the filename+parent_path will decompose them into "/" and "". A slightly controversial topic here may be the treatment of "//". Posix says that paths beginning with "//" may have special meaning and indeed we have code which parses paths like "//net/foo/bar" specially. However, as we were already not being consistent in parsing the "//" string alone, and any special parsing for it would complicate the code further, I chose to treat it the same way as longer sequences of slashes (which are guaranteed to be the same as "/"). Another slight change of behavior is in the parsing of paths like "//net//". Previously the last component of this path was ".". However, as in our parsing the "//net" part in this path was the same as the "drive" part in "c:\" and the next slash was the "root directory", it made sense to treat "//net//" the same way as "//net/" (i.e., not to add the extra "." component at the end). Reviewers: zturner, rnk, dblaikie, Bigcheese Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45942 llvm-svn: 331876
* [AArch64] Improve cost of vector division by constantAdhemerval Zanella2018-05-091-0/+22
| | | | | | | | | | | | | With custom lowering for vector MULLH{S,U}, it is now profitable to vectorize a divide by constant loop for the custom types (v16i8, v8i16, and v4i32). The cost if based on TargetLowering::Build{S,U}DIV which uses a multiply by constant plus adjustment to express a divide by constant. Both {u,s}mull{2} are expressed as Instruction::Mul and shifts by Instruction::AShr. llvm-svn: 331873
* Revert "DWARFVerifier: Check "completeness" of .debug_names section"Pavel Labath2018-05-092-177/+2
| | | | | | | | | | | | | | The new verifier check has found an error in the debug-names-name-collisions.ll test on the PS4 bot: error: Name Index @ 0x0: Entry @ 0xdc: mismatched Name of DIE @ 0x23: index - _ZN3foo3fooE; debug_info - foo. Reverting while I investigate whether this is a bug in the verifier or the generator. This reverts commit r331868. llvm-svn: 331869
* DWARFVerifier: Check "completeness" of .debug_names sectionPavel Labath2018-05-092-2/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a check which makes sure all entries required by the DWARF v5 specification are present in the Name Index. The algorithm tries to follow the wording of Section 6.1.1.1 of the spec as closely as possible. The main deviation from it is that instead of a whitelist-based approach in the spec "The name index must contain an entry for each debugging information entry that defines a named subprogram, label, variable, type, or namespace" I chose a blacklist-based one, where I consider everything to be "in" and then remove the entries that don't make sense. I did this because it has more potential for catching interesting cases and the above is a bit vague (it uses plain words like "variable" and "subprogram", but the rest of the section speaks about specific TAGs). This approach has raised some interesting questions, the main one being whether enumerator values should be indexed. The consensus seems to be that they should, although it does not follow from section 6.1.1.1. For the time being I made the verifier ignore these, as LLVM does not do this yet, and I wanted to get a clean run when verifying generated debug info. Another interesting case was the DW_TAG_imported_declaration. It was not immediately clear to me whether this should go in or not, but currently it is not indexed, and (unlike the enumerators) in does not seem to cause problems for LLDB, so I've also ignored it. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46583 llvm-svn: 331868
* Revert "[InstCombine] snprintf optimizations"Benjamin Kramer2018-05-091-90/+0
| | | | | | | | This reverts commit r331849. It miscompiles snprintf(buf, sizeof(buf), "%s", "any constant string); into memcpy(buf, "%s", sizeof("any constant string")); llvm-svn: 331866
* [X86] Cleanup WriteFStore/WriteVecStore schedulesSimon Pilgrim2018-05-095-121/+10
| | | | | | | | MOVNTPD/MOVNTPS should be WriteFStore Standardized BDW/HSW/SKL/SKX WriteFStore/WriteVecStore - fixes some missed instregex patterns. (V)MASKMOVDQU was already using the default, its costs gets increased but is still nowhere near the real cost of that nasty instruction.... llvm-svn: 331864
* [mips] Move conditional moves out of isCodeGenOnlySimon Dardis2018-05-093-28/+30
| | | | | | | | Reviewers: atanasyan, smaksimovic, abeserminji Differential Revision: https://reviews.llvm.org/D46389 llvm-svn: 331863
* [COFF] Improve correctness of def parsing for GNU featuresMartin Storsjo2018-05-093-12/+20
| | | | | | | | | | | | | | | | | | | | | | | | The operator == used for exporting a function with a different name in the DLL compared to the name in the import library (which is useful for adding linker level aliases for function in the import library) is a feature distinct and different from the operator = used for exporting a function with a different name (both in import library and DLL) than in the implementation producing the DLL. When creating an import library using dlltool, from a def file that contains forwards (Func = OtherDll.Func), this shouldn't affect the produced import library, which should still behave just as if it was a normal exported function. This clears a lot of confusion and subtle misunderstandings, and avoids a parameter that was used to avoid creating weak aliases when invoked from lld. (This parameter was added previously due to the existing conflation of the two features.) Differential Revision: https://reviews.llvm.org/D46245 llvm-svn: 331859
* [MergedLoadStoreMotion] Fix a debug invariant bug in mergeStoresBjorn Pettersson2018-05-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: MergedLoadStoreMotion::mergeStores is using some heuristics to limit the amount of stores that it tries to sink (see MagicCompileTimeControl in MergedLoadStoreMotion.cpp). The heuristic involves counting the number of instructions in one of the basic blocks that is part of the transformation. We now ignore dbg intrinsics when counting instruction for the MagicCompileTimeControl heuristic. This to make sure that the amount of stores that are sunk doesn't depend on the amount of debug information (if -g is used or not). Reviewers: Gerolf, davide, majnemer Reviewed By: davide Subscribers: dberlin, bjope, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46600 llvm-svn: 331852
* [InstCombine] snprintf optimizationsDavid Bolvansky2018-05-091-0/+90
| | | | | | | | | | | | Reviewers: spatel, efriedma, majnemer, rja Reviewed By: rja Subscribers: rja, llvm-commits Differential Revision: https://reviews.llvm.org/D46285 llvm-svn: 331849
* [X86] Combine (vXi1 (bitcast (-1)))) and (vXi1 (bitcast (0))) to all ones or ↵Craig Topper2018-05-091-0/+10
| | | | | | all zeros vXi1 vector. llvm-svn: 331847
* Revert r331816 and r331820 - [globalisel] Add a combiner helpers for ↵Daniel Sanders2018-05-095-146/+1
| | | | | | | | | | extending loads and use them in a pre-legalize combiner for AArch64 Reverting this to see if the clang-cmake-aarch64-global-isel and clang-cmake-aarch64-quick bots are failing because of this commit. We know it wasn't r331819. llvm-svn: 331846
* [DebugInfo] Examine all uses of isDebugValue() for debug instructions.Shiva Chen2018-05-09103-212/+225
| | | | | | | | | | | | | | | | | | Because we create a new kind of debug instruction, DBG_LABEL, we need to check all passes which use isDebugValue() to check MachineInstr is debug instruction or not. When expelling debug instructions, we should expel both DBG_VALUE and DBG_LABEL. So, I create a new function, isDebugInstr(), in MachineInstr to check whether the MachineInstr is debug instruction or not. This patch has no new test case. I have run regression test and there is no difference in regression test. Differential Revision: https://reviews.llvm.org/D45342 Patch by Hsiangkai Wang. llvm-svn: 331844
* [DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.Shiva Chen2018-05-099-0/+141
| | | | | | | | | | | | | | | | | | | | | In order to convert LLVM IR to MachineInstr, we need a new TargetOpcode, DBG_LABEL, to ‘lower’ intrinsic llvm.dbg.label. The patch creates this new TargetOpcode and convert intrinsic llvm.dbg.label to MachineInstr through SelectionDAG. In SelectionDAG, debug information is stored in SDDbgInfo. We create a new data member of SDDbgInfo for labels and use the new data member, SDDbgLabel, to create DBG_LABEL MachineInstr. The new DBG_LABEL MachineInstr uses label metadata from LLVM IR as its parameter. So, the backend could get metadata information of labels from DBG_LABEL MachineInstr. Differential Revision: https://reviews.llvm.org/D45341 Patch by Hsiangkai Wang. llvm-svn: 331842
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-0915-40/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* Revert r331819 [GlobalISel][Legalizer] More concise and faster widenScalar, NFCRoman Tereshin2018-05-092-144/+236
| | | | | | | Reverting this to see if the clang-cmake-aarch64-global-isel and clang-cmake-aarch64-quick bots are failing because of this commit llvm-svn: 331839
* [RuntimeDyld][MachO] Properly handle thumb to thumb calls within a section.Lang Hames2018-05-091-1/+19
| | | | | | | | | | | Previously thumb bits were only checked for external relocations (thumb to arm code and vice-versa). This patch adds detection for thumb callees in the same section asthe (also thumb) caller. The MachO/Thumb test case is updated to cover this, and redundant checks (handled by the MachO/ARM test) are removed. llvm-svn: 331838
* Support a funclet operand bundle in LowerInvokeHeejin Ahn2018-05-091-2/+4
| | | | | | | | | | | | | | | | | Summary: The current LowerInvoke pass cannot handle invoke instructions with a funclet bundle operand. The order of operands for an invoke instruction is {call arguments, callee, funclet operand (if any), normal dest, unwind dest}. The current code assumes there is no funclet operand and incorrectly includes a funclet operand into call arguments. Reviewers: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46242 llvm-svn: 331832
* [SimplifyCFG] Fix a crash when folding PHIs.Davide Italiano2018-05-081-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | We enter MergeBlockIntoPredecessor with a block looking like this: for.inc.us-lcssa: ; preds = %cond.end %k.1.lcssa.ph = phi i32 [ %conv15, %cond.end ] %t.3.lcssa.ph = phi i32 [ %k.1.lcssa.ph, %cond.end ] br label %for.inc, !dbg !66 [note the first arg of the PHI being a PHI]. FoldSingleEntryPHINodes gets rid of both PHIs (calling, eraseFromParent). But right before we call the function, we push into IncomingValues the only argument of the PHIs, and shortly after we try to iterate over something which has been invalidated before :( The fix its not trying to remove PHIs which have an incoming value coming from the same BB we're looking at. Fixes PR37300 and rdar://problem/39910460 Differential Revision: https://reviews.llvm.org/D46568 llvm-svn: 331824
* MC: Remove dead code. NFCI.Peter Collingbourne2018-05-081-1/+0
| | | | | | We should never emit an SHT_DYNSYM into an object file. llvm-svn: 331821
* [globalisel] Correct r331816 to check the opcode before calling getOperand().Daniel Sanders2018-05-081-4/+4
| | | | | | | | | Fix a silly mistake in my pre-commit changes for r331816. It should check what opcode the insn is before extracting the operands. NFC at the moment since the caller already checked the opcode. llvm-svn: 331820
* [GlobalISel][Legalizer] More concise and faster widenScalar, NFCRoman Tereshin2018-05-082-236/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactoring LegalizerHelper::widenScalar member function reducing its size by approximately a factor of 2 and (hopefuly) making it more straightforward and regular by introducing widenScalarSrc and widenScalarDst helper methods. The new widenScalar* methods mutate the instructions in place instead of recreating them from scratch and removing the originals. The compile time implications of this were measured on sqlite3 amalgamation, targeting AArch64 in -O0: LegalizerHelper::widenScalar: > 25% faster Legalizer::runOnMachineFunction: ~ 4.0 - 4.5% faster Also adding MachineOperand::setCImm and refactoring out MachineIRBuilder::recordInsertion methods to make the change possible. Reviewers: aditya_nandakumar, bogner, javed.absar, t.p.northover, ab, dsanders, arsenm Reviewed By: aditya_nandakumar Subscribers: wdng, rovka, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46414 llvm-svn: 331819
* [globalisel] Add a combiner helpers for extending loads and use them in a ↵Daniel Sanders2018-05-085-1/+146
| | | | | | | | | | | | | | | | pre-legalize combiner for AArch64 Summary: Depends on D45541 Reviewers: ab, aditya_nandakumar, bogner, rtereshin, volkan, rovka, javed.absar, aemerson Reviewed By: aemerson Subscribers: aemerson, rengolin, mgorny, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D45543 llvm-svn: 331816
* Revert "[X86][CET] Shadow stack fix for setjmp/longjmp"Jessica Paquette2018-05-082-251/+5
| | | | | | | | | | | | This reverts commit 30962eca38ef02666ebcdded72a94f2cd0292d68. This commit has been causing test asan failures on a build bot. http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/45108/ Original commit: https://reviews.llvm.org/D46181 llvm-svn: 331813
* [AsmPrinter] Allow emitting codeview for any windows targetMartin Storsjo2018-05-081-2/+1
| | | | | | | | | | | | | | | | Before SVN r244158, codeview debug info was emitted always emitted for msvc if debug info was enabled, but that commit added a module flag. Since it's still restricted by the flag, we can allow it for any target if the user requests it, not only msvc (and windows-itanium, added in SVN r287567). Add a test for emitting it for a mingw target. Differential Revision: https://reviews.llvm.org/D46303 llvm-svn: 331809
* [Coverage] Take filenames into account when loading function records.Max Moroz2018-05-081-2/+4
| | | | | | | | | | | | | | | | | | | | Summary: Don't skip functions with the same name but from different files. That change makes it possible to generate code coverage reports from different binaries compiled from different sources even if there are functions with non-unique names. Without that change, code coverage for such functions is missing except of the first function processed. Reviewers: vsk, morehouse Reviewed By: vsk Subscribers: llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D46478 llvm-svn: 331801
* [LV] Fix for PR37248, Broadcast codegen incorrectly assumed vector loop body ↵Hideki Saito2018-05-081-5/+7
| | | | | | | | | | | | | | | | | | | is single basic block Summary: Broadcast code generation emitted instructions in pre-header, while the instruction they are dependent on in the vector loop body. This resulted in an IL verification error ---- value used before defined. Reviewers: rengolin, fhahn, hfinkel Reviewed By: rengolin, fhahn Subscribers: dcaballe, Ka-Ka, llvm-commits Differential Revision: https://reviews.llvm.org/D46302 llvm-svn: 331799
* [AMDGPU] Provide machine -> name mappingTim Renouf2018-05-082-51/+70
| | | | | | | | | | | | | | | Summary: AMDGPU stores a numerical code for the particular GPU variant in EFlags in the ELF file. This commit provides a mapping from that number into the machine name for use by objdump-type tools. Change-Id: Id37fc0bebad443bd89c0080985ce298c4e7e9319 Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits Differential Revision: https://reviews.llvm.org/D46587 llvm-svn: 331798
* [Power9]Legalize and emit code for truncate and convert QP to HW and ByteLei Huang2018-05-081-2/+14
| | | | | | | | | Legalize and emit code for truncate and convert float128 to (un)signed short and (un)signed char. Differential Revision: https://reviews.llvm.org/D46194 llvm-svn: 331797
OpenPOWER on IntegriCloud