summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [SelectionDAG] allow undefs when matching splat constantsSanjay Patel2018-10-051-7/+4
| | | | | | | | | And use that to transform fsub with zero constant operands. The integer part isn't used yet, but it is proposed for use in D44548, so adding both enhancements here makes that patch simpler. llvm-svn: 343865
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-1/+1
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* Run VerifyDAGDiverence in debug onlyMikael Nilsson2018-09-261-0/+2
| | | | | | | | | VerifyDAGDiverence costs compilation time, avoid running it in non-debug builds. Differential Revision: https://reviews.llvm.org/D52454 llvm-svn: 343086
* [x86] avoid 256-bit andnp that requires insert/extract with AVX1 (PR37449)Sanjay Patel2018-09-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the final (I hope!) problem pattern mentioned in PR37749: https://bugs.llvm.org/show_bug.cgi?id=37749 We are trying to avoid an AVX1 sinkhole caused by having 256-bit bitwise logic ops but no other 256-bit integer ops. We've already solved the simple logic ops, but 'andn' is an x86 special. I looked at alternative solutions like extending the generic DAG combine or trying to wait until the ANDNP node is created, but those are bigger patches that can over-reach. Ie, splitting to 128-bit does not look like a win in most cases with >1 256-bit op. The pattern matching is cluttered with bitcasts because of our i64 element canonicalization. For the affected test, we have this vector-type-legalized sequence: t29: v8i32 = concat_vectors t27, t28 t30: v4i64 = bitcast t29 t18: v8i32 = BUILD_VECTOR Constant:i32<-1>, Constant:i32<-1>, ... t31: v4i64 = bitcast t18 t32: v4i64 = xor t30, t31 t9: v8i32 = BUILD_VECTOR Constant:i32<255>, Constant:i32<255>, ... t34: v4i64 = bitcast t9 t35: v4i64 = and t32, t34 t36: v8i32 = bitcast t35 t37: v4i32 = extract_subvector t36, Constant:i64<0> t38: v4i32 = extract_subvector t36, Constant:i64<4> Differential Revision: https://reviews.llvm.org/D52318 llvm-svn: 343008
* [SelectionDAG] replace duplicated peekThroughBitcast helper functions; NFCISanjay Patel2018-09-201-0/+12
| | | | | | | | | | | | | | x86 had 2 versions of peekThroughBitcast. DAGCombiner had 1. Plus, it had a 1-off implementation for the one-use variant. Move the x86 versions of the code to SelectionDAG, so we don't have different copies of the code. No functional change intended. I'm putting this next to isBitwiseNot() because I am planning to use it in there. Another option is next to the helpers in the ISD namespace (eg, ISD::isConstantSplatVector()). But if there's no good reason for those to be there, I'd prefer to pull other helpers over to SelectionDAG in follow-up steps. Differential Revision: https://reviews.llvm.org/D52285 llvm-svn: 342669
* [SelectionDAG] allow vector types with isBitwiseNot()Sanjay Patel2018-09-191-1/+4
| | | | | | | The test diff in not-and-simplify.ll is from a use in SimplifyDemandedBits, and the test diff in add.ll is from a DAGCombiner transform. llvm-svn: 342594
* Fix debug info for SelectionDAG legalization of DAG nodes with two results.Adrian Prantl2018-09-141-1/+1
| | | | | | | | | | | | | | | | This patch fixes the debug info handling for SelectionDAG legalization of DAG nodes with two results. When an replaced SDNode has more than one result, transferDbgValues was always copying the SDDbgValue from the first result and attaching them to all members. In reality SelectionDAG::ReplaceAllUsesWith() is given an array of SDNodes (though the type signature doesn't make this obvious (cf. the call site code in ReplaceNode()). rdar://problem/44162227 Differential Revision: https://reviews.llvm.org/D52112 llvm-svn: 342264
* [CodeGen] Fix remaining zext() assertions in SelectionDAGScott Linder2018-09-041-2/+2
| | | | | | | | Fix remaining cases not committed in https://reviews.llvm.org/D49574 Differential Revision: https://reviews.llvm.org/D50659 llvm-svn: 341380
* DAG: Handle extract_vector_elt in isKnownNeverNaNMatt Arsenault2018-09-031-0/+3
| | | | llvm-svn: 341317
* [NFC] Rename the DivergenceAnalysis to LegacyDivergenceAnalysisNicolai Haehnle2018-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This is patch 1 of the new DivergenceAnalysis (https://reviews.llvm.org/D50433). The purpose of this patch is to free up the name DivergenceAnalysis for the new generic implementation. The generic implementation class will be shared by specialized divergence analysis classes. Patch by: Simon Moll Reviewed By: nhaehnle Subscribers: jvesely, jholewinski, arsenm, nhaehnle, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50434 Change-Id: Ie8146b11be2c50d5312f30e11c7a3036a15b48cb llvm-svn: 341071
* [X86] Support v2i32 gather/scatter indices with ↵Craig Topper2018-08-291-2/+2
| | | | | | | | | | | | | | | | -x86-experimental-vector-widening-legalization Summary: This is split out from D41062 to cover the code in LegalVectorTypes.cpp Reviewers: RKSimon, spatel, efriedma Reviewed By: efriedma Subscribers: sdardis, jvesely, nhaehnle, jrtc27, atanasyan, llvm-commits Differential Revision: https://reviews.llvm.org/D51337 llvm-svn: 340891
* [DAG] Avoid recomputing Divergence checks. NFCI.Nirav Dave2018-08-281-6/+10
| | | | | | | When making multiple updates to the same SDNode, recompute node divergence only once after all changes have been made. llvm-svn: 340852
* [DAG] Fix updateDivergence calculationNirav Dave2018-08-281-1/+1
| | | | | | | Check correct SDNode when deciding if we should update the divergence property. llvm-svn: 340851
* [SelectionDAG][X86] Reorder the operands the MaskedStoreSDNode to put the ↵Craig Topper2018-08-251-3/+3
| | | | | | | | | | | | | | | | | | | | | value first. Summary: Previously the value being stored is the last operand in SDNode. This causes the type legalizer to visit the mask operand before the value operand. The type legalizer was more complicated because of this since we want the type of the value to drive the decisions. This patch moves the value to be the first operand so we visit it first during type legalization. It also simplifies the type legalization code accordingly. X86 is currently the only in tree target that uses this SDNode. Not sure if there are any users out of tree. Reviewers: RKSimon, delena, hfinkel, eli.friedman Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D50402 llvm-svn: 340689
* [SDAG] Add versions of computeKnownBits that return a valueJustin Bogner2018-08-241-93/+81
| | | | | | | | | | | Having the KnownBits as an output parameter is kind of awkward to use and a holdover from when it was two separate APInts. Instead, just return a KnownBits object. I'm leaving the existing interface in place for now, since updating the callers all at once would be thousands of lines of diff. llvm-svn: 340594
* [SelectionDAG] Reuse the Op's VT. NFCI.Simon Pilgrim2018-08-201-2/+2
| | | | llvm-svn: 340173
* [SelectionDAG] Add partial sign-bit support to ComputeNumSignBits for ↵Simon Pilgrim2018-08-201-2/+16
| | | | | | | | | | BITCAST nodes Only adds support to the existing 'large element' scalar/vector to 'small element' vector bitcasts. Handle the case where the sign bit extends to only part of the small elements. llvm-svn: 340169
* [SelectionDAG] Add basic demanded elements support to ComputeNumSignBits for ↵Simon Pilgrim2018-08-191-1/+8
| | | | | | | | | | BITCAST nodes Only adds support to the existing 'large element' scalar/vector to 'small element' vector bitcasts. The next step would be to support cases where the large elements aren't all sign bits, and determine the small element equivalent based on the demanded elements. llvm-svn: 340143
* DAG: Fix isKnownNeverNaN for basic non-sNaN casesMatt Arsenault2018-08-171-12/+7
| | | | | | | fadd/fsub/fmul need to worry about infinities as well as fdiv. llvm-svn: 340085
* [SDAG] Remove the reliance on MI's allocation strategy forChandler Carruth2018-08-141-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `MachineMemOperand` pointers attached to `MachineSDNodes` and instead have the `SelectionDAG` fully manage the memory for this array. Prior to this change, the memory management was deeply confusing here -- The way the MI was built relied on the `SelectionDAG` allocating memory for these arrays of pointers using the `MachineFunction`'s allocator so that the raw pointer to the array could be blindly copied into an eventual `MachineInstr`. This creates a hard coupling between how `MachineInstr`s allocate their array of `MachineMemOperand` pointers and how the `MachineSDNode` does. This change is motivated in large part by a change I am making to how `MachineFunction` allocates these pointers, but it seems like a layering improvement as well. This would run the risk of increasing allocations overall, but I've implemented an optimization that should avoid that by storing a single `MachineMemOperand` pointer directly instead of allocating anything. This is expected to be a net win because the vast majority of uses of these only need a single pointer. As a side-effect, this makes the API for updating a `MachineSDNode` and a `MachineInstr` reasonably different which seems nice to avoid unexpected coupling of these two layers. We can map between them, but we shouldn't be *surprised* at where that occurs. =] Differential Revision: https://reviews.llvm.org/D50680 llvm-svn: 339740
* [CodeGen] Fix assert in SelectionDAG::computeKnownBitsScott Linder2018-08-131-2/+2
| | | | | | | | | | Fix SelectionDAG::computeKnownBits asserting when handling EXTRACT_SUBVECTOR when zero extending the demanded elements mask if it is already as long as the source vector. Differential Revision: https://reviews.llvm.org/D49574 llvm-svn: 339600
* [SelectionDAG][X86] Rename getValue to getPassThru for gather SDNodes.Craig Topper2018-08-071-1/+1
| | | | | | getValue is more meaningful name for scatter than it is for gather. Split them and use getPassThru for gather. llvm-svn: 339096
* DAG: Enhance isKnownNeverNaNMatt Arsenault2018-08-031-8/+89
| | | | | | | | | | | | Add a parameter for testing specifically for sNaNs - at least one instruction pattern on AMDGPU needs to check specifically for this. Also handle more cases, and add a target hook for custom nodes, similar to the hooks for known bits. llvm-svn: 338910
* [NFC] small addendum to r334242, FMF propagationMichael Berg2018-08-011-1/+1
| | | | llvm-svn: 338604
* [SelectionDAG] Make binop reduction matcher available to all targetsSimon Pilgrim2018-08-011-0/+58
| | | | | | | | There is nothing x86-specific about this code, so it'd be nice to make this available for other targets to use in the future (and get it out of X86ISelLowering!). Differential Revision: https://reviews.llvm.org/D50083 llvm-svn: 338586
* [SelectionDAG] Add MLOAD/MSTORE/MGATHER/MSCATTER to AddNodeIDCustom to ↵Craig Topper2018-07-261-0/+28
| | | | | | properly calculate their folding set ID to allow them to be CSEd. llvm-svn: 338080
* [DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst usersVedant Kumar2018-07-261-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LowerDbgDeclare inserts a dbg.value before each use of an address described by a dbg.declare. When inserting a dbg.value before a CallInst use, however, it fails to append DW_OP_deref to the DIExpression. The DW_OP_deref is needed to reflect the fact that a dbg.value describes a source variable directly (as opposed to a dbg.declare, which relies on pointer indirection). This patch adds in the DW_OP_deref where needed. This results in the correct values being shown during a debug session for a program compiled with ASan and optimizations (see https://reviews.llvm.org/D49520). Note that ConvertDebugDeclareToDebugValue is already correct -- no changes there were needed. One complication is that SelectionDAG is unable to distinguish between direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also fixes this long-standing issue in order to not regress integration tests relying on the incorrect assumption that all frame-index SDDbgValues are indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot be lowered properly otherwise. Basically the fix prevents a direct SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice by a debugger. There were a handful of tests relying on this incorrect "FRAMEIX => indirect" assumption which actually had incorrect DW_AT_locations: these are all fixed up in this patch. Testing: - check-llvm, and an end-to-end test using lldb to debug an optimized program. - Existing unit tests for DIExpression::appendToStack fully cover the new DIExpression::append utility. - check-debuginfo (the debug info integration tests) Differential Revision: https://reviews.llvm.org/D49454 llvm-svn: 338069
* [SelectionDAG] Add constant buildvector support to isKnownNeverZeroSimon Pilgrim2018-07-111-2/+8
| | | | | | This allows us to use SelectionDAG::isKnownNeverZero in DAGCombiner::visitREM (visitSDIVLike/visitUDIVLike handle the checking for constants). llvm-svn: 336779
* [SelectionDAG] Add VT consistency checks to the creation of ISD::FMA.Craig Topper2018-07-091-0/+3
| | | | | | This is similar to what is done for binops. I don't know if this would have helped us catch the bug fixed in r336566 earlier or not, but I figured it couldn't hurt. llvm-svn: 336576
* [SelectionDAG] Split float and integer isKnownNeverZero testsSimon Pilgrim2018-07-071-1/+11
| | | | | | | | | | Splits off isKnownNeverZeroFloat to handle +/- 0 float cases. This will make it easier to be more aggressive with the integer isKnownNeverZero tests (similar to ValueTracking), use computeKnownBits etc. Differential Revision: https://reviews.llvm.org/D48969 llvm-svn: 336492
* [SelectionDAG] Remove debug locations from ConstantSD(FP)NodesVedant Kumar2018-06-251-2/+2
| | | | | | | | | | | | | | | | | | This removes debug locations from ConstantSDNode and ConstantSDFPNode. When this kind of node is materialized we no longer create a line table entry which jumps back to the constant's first point of use. This makes single-stepping behavior smoother, and it matches the model used by IR, where Constants have no locations. See this thread for more context: http://lists.llvm.org/pipermail/llvm-dev/2018-June/124164.html I'd like to handle constant BuildVectorSDNodes and to try to eliminate passing SDLocs to SelectionDAG::getConstant*() in follow-up commits. Differential Revision: https://reviews.llvm.org/D48468 llvm-svn: 335497
* Utilize new SDNode flag functionality to expand current support for faddMichael Berg2018-06-181-18/+0
| | | | | | | | | | | | | | Summary: This patch originated from D46562 and is a proper subset, with some issues addressed. Reviewers: spatel, hfinkel, wristow, arsenm, javed.absar Reviewed By: spatel Subscribers: wdng, nhaehnle Differential Revision: https://reviews.llvm.org/D47909 llvm-svn: 334996
* propagate fast math flags via IR on fma and sub expressionsMichael Berg2018-06-071-2/+6
| | | | | | | | | | | | | | Summary: This change uses fmf subflags to guard fma optimizations as well as unsafe. These changes originated from D46483 and have been simplified via getNode. Reviewers: spatel, arsenm, hfinkel, javed.absar Reviewed By: spatel Subscribers: nemanjai, wdng Differential Revision: https://reviews.llvm.org/D47388 llvm-svn: 334242
* guard fneg with fmf sub flagsMichael Berg2018-06-051-3/+3
| | | | | | | | | | | | | | Summary: This change uses fmf subflags to guard optimizations as well as unsafe. These changes originated from D46483. Reviewers: spatel, hfinkel Reviewed By: spatel Subscribers: nemanjai Differential Revision: https://reviews.llvm.org/D47389 llvm-svn: 334037
* [CodeGen] Always update divergence in SelectionDAG::UpdateNodeOperandsScott Linder2018-06-041-0/+2
| | | | | | | | Some overloads failed to update divergence. Differential Revision: https://reviews.llvm.org/D47148 llvm-svn: 333947
* [DAG] fold FP binops with undef operands to NaNSanjay Patel2018-05-211-11/+12
| | | | | | | | | | | | | | | | | | This is the FP sibling of D43141 with the corresponding IR change in rL327212. We can't propagate undef here because if a variable operand is a NaN, these binops must propagate NaN. Neither global nor node-level fast-math makes a difference. If we have 'nnan', I think later folds can turn the NaN into undef. The tests in X86/fp-undef.ll are meant to be the definitive verification for these folds - everything reduces identically now. The other test changes are collateral damage. They may need to be altered to preserve their intent. Differential Revision: https://reviews.llvm.org/D47026 llvm-svn: 332920
* [AArch64] Gangup loads and stores for pairing.Sirish Pande2018-05-161-4/+85
| | | | | | | | | | Keep loads and stores together (target defines how many loads and stores to gang up), such that it will help in pairing and vectorization. Differential Revision https://reviews.llvm.org/D46477 llvm-svn: 332482
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-6/+4
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [DebugInfo] Convert intrinsic llvm.dbg.label to MachineInstr.Shiva Chen2018-05-091-0/+12
| | | | | | | | | | | | | | | | | | | | | 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
* [SelectionDAG] Transfer DbgValues when casts are optimized in ↵Aaron Smith2018-05-071-2/+4
| | | | | | | | | | | | | | | | | | | | | SelectionDAG::getNode Summary: getNode optimizes (ext (trunc x)) to x and the dbgvalue node on trunc is lost. The fix calls transferDbgValues to add the dbgvalue to x. Add DebugInfo/AArch64/dbg-value-i16.ll Patch by Sejong Oh! Reviewers: aprantl, javed.absar, llvm-commits, vsk Reviewed By: aprantl, vsk Subscribers: kristof.beyls, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46348 llvm-svn: 331665
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-011-3/+3
| | | | | | | | | | | | | | | | We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
* [SelectionDAG] Improve selection of DBG_VALUE using a PHI node resultBjorn Pettersson2018-04-301-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building the selection DAG at ISel all PHI nodes are selected and lowered to Machine Instruction PHI nodes before we start to create any SDNodes. So there are no SDNodes for values produced by the PHI nodes. In the past when selecting a dbg.value intrinsic that uses the value produced by a PHI node we have been handling such dbg.value intrinsics as "dangling debug info". I.e. we have not created a SDDbgValue node directly, because there is no existing SDNode for the PHI result, instead we deferred the creationg of a SDDbgValue until we found the first use of the PHI result. The old solution had a couple of flaws. The position of the selected DBG_VALUE instruction would end up quite late in a basic block, and for example not directly after the PHI node as in the LLVM IR input. And in case there were no use at all in the basic block the dbg.value could be dropped completely. This patch introduces a new VREG kind of SDDbgValue nodes. It is similar to a SDNODE kind of node, but it refers directly to a virtual register and not a SDNode. When we do selection for a dbg.value that is using the result of a PHI node we can do a lookup of the virtual register directly (as it already is determined for the PHI node) and create a SDDbgValue node immediately instead of delaying the selection until we find a use. This should fix a problem with losing debug info at ISel as seen in PR37234 (https://bugs.llvm.org/show_bug.cgi?id=37234). It does not resolve PR37234 completely, because the debug info is dropped later on in the BranchFolder (see D46184). Reviewers: #debug-info, aprantl Reviewed By: #debug-info, aprantl Subscribers: rnk, gbedwell, aprantl, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D46129 llvm-svn: 331182
* [SelectionDAG] Refactor lowering of atomic memory intrinsics.Daniel Neilson2018-04-231-0/+122
| | | | | | | | | | | Summary: This just refactors the lowering of the atomic memory intrinsics to more closely match the code patterns used in the lowering of the non-atomic memory intrinsics. Specifically, we encapsulate the lowering in SelectionDAG::getAtomicMem*() functions rather than embedding the code directly in the SelectionDAGBuilder code. llvm-svn: 330603
* [SelectionDAG][NFC] haveNoCommonBitsSet(): add FIXME notesRoman Lebedev2018-04-151-0/+2
| | | | | | As suggested in https://reviews.llvm.org/D45631#1068338 llvm-svn: 330102
* [CodeGen] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: bogner, rnk, MatzeB, RKSimon Reviewed By: rnk Subscribers: JDevlieghere, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D45133 llvm-svn: 329435
* [IR][CodeGen] Remove dependency on EVT from IR/Function.cpp. Move EVT to ↵Craig Topper2018-03-291-1/+1
| | | | | | | | | | | | CodeGen layer. Currently EVT is in the IR layer only because of Function.cpp needing a very small piece of the functionality of EVT::getEVTString(). The rest of EVT is used in codegen making CodeGen a better place for it. The previous code converted a Type* to EVT and then called getEVTString. This was only expected to handle the primitive types from Type*. Since there only a few primitive types, we can just print them as strings directly. Differential Revision: https://reviews.llvm.org/D45017 llvm-svn: 328806
* Fix layering by moving ValueTypes.h from CodeGen to IRDavid Blaikie2018-03-231-1/+1
| | | | | | ValueTypes.h is implemented in IR already. llvm-svn: 328397
* Fix layering of MachineValueType.h by moving it from CodeGen to SupportDavid Blaikie2018-03-231-1/+1
| | | | | | | | | This is used by llvm tblgen as well as by LLVM Targets, so the only common place is Support for now. (maybe we need another target for these sorts of things - but for now I'm at least making them correct & we can make them better if/when people have strong feelings) llvm-svn: 328395
* [SelectionDAG] Handle big endian target BITCAST in computeKnownBits()Jonas Paulsson2018-03-171-6/+5
| | | | | | | | | | | | | | | The BITCAST handling in computeKnownBits() previously only worked for little endian. This patch reverses the iteration over elements for a big endian target which allows this to work in this case also. SystemZ test case. Review: Eli Friedman https://reviews.llvm.org/D44249 llvm-svn: 327764
* [x86][aarch64] ask the backend whether it has a vector blend instructionSebastian Pop2018-03-091-24/+26
| | | | | | | | | | | | | The code to match and produce more x86 vector blends was enabled for all architectures even though the transform may pessimize the code for other architectures that do not provide a vector blend instruction. Added an aarch64 testcase to check that a VZIP instruction is generated instead of byte movs. Differential Revision: https://reviews.llvm.org/D44118 llvm-svn: 327132
OpenPOWER on IntegriCloud