summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAGCombiner] Add a DAG combine to turn a splat build_vector where the splat ↵Craig Topper2018-01-181-0/+23
| | | | | | | | | | elemnt is a bitcast from a vector type into a concat_vector For example, a build_vector of i64 bitcasted from v2i32 can be turned into a concat_vectors of the v2i32 vectors with a bitcast to a vXi64 type Differential Revision: https://reviews.llvm.org/D42090 llvm-svn: 322811
* [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization.Eli Friedman2018-01-171-2/+2
| | | | | | | | | | | | | The code wasn't zero-extending correctly, so the comparison could spuriously fail. Adds some AArch64 tests to cover this case. Inspired by D41791. Differential Revision: https://reviews.llvm.org/D41798 llvm-svn: 322767
* Revert "[DAG] Elide overlapping stores"Benjamin Kramer2018-01-151-20/+21
| | | | | | | This reverts commit r322085. Internal PPC testing is still showing the same symptoms as when this patch landed the last time. llvm-svn: 322474
* [NFC] Change MemIntrinsicInst::setAlignment() to take an unsigned instead of ↵Daniel Neilson2018-01-121-6/+9
| | | | | | | | | | | a Constant Summary: In preparation for https://reviews.llvm.org/D41675 this NFC changes this prototype of MemIntrinsicInst::setAlignment() to accept an unsigned instead of a Constant. llvm-svn: 322403
* dag-combine: Transfer debug information when folding (zext (truncate x))Adrian Prantl2018-01-111-1/+4
| | | | | | | | | | | -> (zext (truncate x)) This patch adds debug info support to the dagcombine rule (zext (truncate x)) -> (zext (truncate x)). Differential Revision: https://reviews.llvm.org/D41924 llvm-svn: 322304
* DAGCombine: Let truncates negate extension through extract-subvectorZvi Rackover2018-01-111-0/+16
| | | | | | | | | | | | | | | | | | | | | | Summary: Fold cases such as: (v8i8 truncate (v8i32 extract_subvector (v16i32 sext (v16i8 V), Idx))) -> (v8i8 extract_subvector (v16i8 V), Idx) This can be generalized to cases where the truncate and extend do not fully cancel each other out, but it may require querying the target about profitability. Reviewers: RKSimon, craig.topper, spatel, efriedma Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41927 llvm-svn: 322300
* [VectorLegalizer] Remove broken code in ExpandStore.Jonas Paulsson2018-01-111-28/+0
| | | | | | | | | | | | | | The code that is supposed to "Round odd types to the next pow of two" seems broken and as well completely unused (untested). It also seems that ExpandStore really shouldn't ever change the memory VT, which this in fact does. As a first step in fixing the broken handling of vector stores (of irregular types, e.g. an i1 vector), this code is removed. For discussion, see https://bugs.llvm.org/show_bug.cgi?id=35520. Review: Eli Friedman llvm-svn: 322275
* [SelectionDAG][X86] Explicitly store the scale in the gather/scatter ISD nodesCraig Topper2018-01-105-24/+46
| | | | | | | | | | Currently we infer the scale at isel time by analyzing whether the base is a constant 0 or not. If it is we assume scale is 1, else we take it from the element size of the pass thru or stored value. This seems a little weird and I think it makes more sense to make it explicit in the DAG rather than doing tricky things in the backend. Most of this patch is just making sure we copy the scale around everywhere. Differential Revision: https://reviews.llvm.org/D40055 llvm-svn: 322210
* [SelectionDAGBuilder] Chain prefetches less aggressively.Jonas Paulsson2018-01-101-7/+13
| | | | | | | | | | | | | Prefetches used to always be chained between any previous and following memory accesses. The problem with this was that later optimizations, such as folding of a load into the user instruction, got disrupted. This patch relaxes the chaining of prefetches in order to remedy this. Reveiw: Hal Finkel https://reviews.llvm.org/D38886 llvm-svn: 322163
* [SelectionDAG] Fixed f16-from-vector promotion problemTim Renouf2018-01-091-1/+7
| | | | | | | | | | | | | | | | | | Summary: In the case of an fp_extend of v1f16 to v1f32 where the v1f16 is the result of a bitcast from i16, avoid creating an illegal fp16_to_fp where the input is not a vector and the result is a v1f32. V2: The fix is now to avoid vector scalarization creating a v1->scalar bitcast. Reviewers: srhines, t.p.northover Subscribers: nhaehnle, llvm-commits, dstuttard, t-tye, yaxunl, wdng, kzhuravl, arsenm Differential Revision: https://reviews.llvm.org/D41126 llvm-svn: 322120
* [SelectionDAG] lower math intrinsics to finite version of libcalls when ↵Sanjay Patel2018-01-093-20/+65
| | | | | | | | | | | | | | | | | | | | | | possible (PR35672) Ingredients in this patch: 1. Add HANDLE_LIBCALL defs for finite mathlib functions that correspond to LLVM intrinsics. 2. Plumbing to send TargetLibraryInfo down to SelectionDAGLegalize. 3. Relaxed math and library checking in SelectionDAGLegalize::ConvertNodeToLibcall() to choose finite libcalls. There was a bug about determining the availability of the finite calls that should be fixed with: rL322010 Not in this patch: This doesn't resolve the question/bug of clang creating the intrinsic IR in the first place. There's likely follow-up work needed to support the long double variants better. There's room for improvement to reduce the code duplication. Create finite calls that don't originate from a corresponding intrinsic or DAG node? Differential Revision: https://reviews.llvm.org/D41338 llvm-svn: 322087
* [DAG] Elide overlapping storesNirav Dave2018-01-091-21/+20
| | | | | | | | | | | | | | | | Relanding after fixing handling of pre-indexed memory operations in BaseIndexOffset analysis (r322003). Extend overlapping store elision to handle overwrites of stores by larger stores. Reviewers: craig.topper, rnk, t.p.northover Subscribers: javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40969 llvm-svn: 322085
* [DAG] Teach BaseIndexOffset to correctly handle with indexed operationsNirav Dave2018-01-083-51/+69
| | | | | | | | | | | | | | BaseIndexOffset address analysis incorrectly ignores offsets folded into indexed memory operations causing potential errors in alias analysis of pre-indexed operations. Reviewers: efriedma, RKSimon, hfinkel, jyknight Subscribers: hiraditya, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D41701 llvm-svn: 322003
* [DAGCombine] Fix for PR35761Sam Parker2018-01-081-4/+10
| | | | | | | | | | | I had falsely assumed that constant operands would be operand(1) of the bin ops that may need their constant operand to be masked. Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=35761 Differential Revision: https://reviews.llvm.org/D41667 llvm-svn: 321991
* [DAG] Fix for Bug PR34620 - Allow SimplifyDemandedBits to look through bitcastsSimon Pilgrim2018-01-071-0/+6
| | | | | | | | | | Allow SimplifyDemandedBits to use TargetLoweringOpt::computeKnownBits to look through bitcasts. This can help simplifying in some cases where bitcasts of constants generated during or after legalization can't be folded away, and thus didn't get picked up by SimplifyDemandedBits. This fixes PR34620, where a redundant pand created during legalization from lowering and lshr <16xi8> wasn't being simplified due to the presence of a bitcasted build_vector as an operand. Committed on the behalf of @sameconrad (Sam Conrad) Differential Revision: https://reviews.llvm.org/D41643 llvm-svn: 321969
* [X86] Make v2i1 and v4i1 legal types without VLXCraig Topper2018-01-071-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are few oddities that occur due to v1i1, v8i1, v16i1 being legal without v2i1 and v4i1 being legal when we don't have VLX. Particularly during legalization of v2i32/v4i32/v2i64/v4i64 masked gather/scatter/load/store. We end up promoting the mask argument to these during type legalization and then have to widen the promoted type to v8iX/v16iX and truncate it to get the element size back down to v8i1/v16i1 to use a 512-bit operation. Since need to fill the upper bits of the mask we have to fill with 0s at the promoted type. It would be better if we could just have the v2i1/v4i1 types as legal so they don't undergo any promotion. Then we can just widen with 0s directly in a k register. There are no real v4i1/v2i1 instructions anyway. Everything is done on a larger register anyway. This also fixes an issue that we couldn't implement a masked vextractf32x4 from zmm to xmm properly. We now have to support widening more compares to 512-bit to get a mask result out so new tablegen patterns got added. I had to hack the legalizer for widening the operand of a setcc a bit so it didn't try create a setcc returning v4i32, extract from it, then try to promote it using a sign extend to v2i1. Now we create the setcc with v4i1 if the original setcc's result type is v2i1. Then extract that and don't sign extend it at all. There's definitely room for improvement with some follow up patches. Reviewers: RKSimon, zvi, guyblank Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41560 llvm-svn: 321967
* [PowerPC] Add an ISD::TRUNCATE to the legalization for ↵Craig Topper2018-01-071-13/+2
| | | | | | | | | | | | | | | | | | | | | ppc_is_decremented_ctr_nonzero Summary: I believe legalization is really expecting that ReplaceNodeResults will return something with the same type as the thing that's being legalized. Ultimately, it uses the output to replace the uses in the DAG so the type should match to make that work. There are two relevant cases here. When crbits are enabled, then i1 is a legal type and getSetCCResultType should return i1. In this case, the truncate will be between i1 and i1 and should be removed (SelectionDAG::getNode does this). Otherwise, getSetCCResultType will be i32 and the legalizer will promote the truncate to be i32 -> i32 which will be similarly removed. With this fixed we can remove some code from PromoteIntRes_SETCC that seemed to only exist to deal with the intrinsic being replaced with a larger type without changing the other operand. With the truncate being used for connectivity this doesn't happen anymore. Reviewers: hfinkel Reviewed By: hfinkel Subscribers: nemanjai, llvm-commits, kbarton Differential Revision: https://reviews.llvm.org/D41654 llvm-svn: 321959
* [DAGCombine] Fix for PR37563Sam Parker2018-01-051-2/+12
| | | | | | | | | | | | While searching for loads to be narrowed, equal sized loads were not added to the list, resulting in anyext loads not being converted to zext loads. https://bugs.llvm.org/show_bug.cgi?id=35763 Differential Revision: https://reviews.llvm.org/D41628 llvm-svn: 321862
* [DAGCombine] Ensure SDNode use iterator is incremented properly.Amara Emerson2018-01-041-2/+2
| | | | | | Fixes an ASAN bug found by oss-fuzz. llvm-svn: 321813
* [DAGCombine] Handle out of range EXTRACT_VECTOR_ELT indices Simon Pilgrim2018-01-032-1/+5
| | | | | | | | Handle this in DAGCombiner::visitEXTRACT_VECTOR_ELT the same as we already do in SelectionDAG::getNode and use APInt instead of getZExtValue. This should also fix oss-fuzz #4910 llvm-svn: 321767
* Revert r321089: "[DAG] Elide overlapping store" (and subsequent fix in r321204)Daniel Jasper2018-01-021-21/+21
| | | | | | | Our internal testing has revealed has discovered bugs in PPC builds. I have forward reproduction instructions to the original author (Nirav). llvm-svn: 321649
* [DAGCombine] Fix for PR35765Sam Parker2018-01-021-1/+0
| | | | | | | | | | | Remove the acceptance of ANY_EXTEND nodes while trying to move and nodes back to loads. Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=35765 Differential Revision: https://reviews.llvm.org/D41625 llvm-svn: 321641
* [SelectionDAG] Teach WidenVecOp_Convert to widen the operation if a widened ↵Craig Topper2018-01-021-4/+13
| | | | | | result type would still be legal. llvm-svn: 321638
* [SelectionDAG] Remove ifs on getTypeAction being TypeWidenVector from some ↵Craig Topper2018-01-021-9/+11
| | | | | | | | of the WideVecOp handlers. We should only be in the handler if the tyep action is TypeWidenVector. There's no reason to try to do anything else. llvm-svn: 321635
* [SelectionDAG][X86][AArch64] Require targets to specify the promotion type ↵Craig Topper2018-01-011-37/+21
| | | | | | | | | | | | | | | | when using setOperationAction Promote for INT_TO_FP and FP_TO_INT Currently the promotion for these ignores the normal getTypeToPromoteTo and instead just tries to double the element width. This is because the default behavior of getTypeToPromote to just adds 1 to the SimpleVT, which has the affect of increasing the element count while keeping the scalar size the same. If multiple steps are required to get to a legal operation type, int_to_fp will be promoted multiple times. And fp_to_int will keep trying wider types in a loop until it finds one that works. getTypeToPromoteTo does have the ability to query a promotion map to get the type and not do the increasing behavior. It seems better to just let the target specify the promotion type in the map explicitly instead of letting the legalizer iterate via widening. FWIW, it's worth I think for any other vector operations that need to be promoted, we have to specify the type explicitly because the default behavior of getTypeToPromote isn't useful for vectors. The other types of promotion already require either the element count is constant or the total vector width is constant, but neither happens by incrementing the SimpleVT enum. Differential Revision: https://reviews.llvm.org/D40664 llvm-svn: 321629
* Use phi ranges to simplify code. No functionality change intended.Benjamin Kramer2017-12-304-26/+22
| | | | llvm-svn: 321585
* Avoid modifying DbgInfo while looping in salvageDebuginfoDimitry Andric2017-12-281-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I have been getting rather difficult to reproduce SIGBUS crashes when compiling certain FreeBSD sources, and their stack traces pointed squarely at `SelectionDAG::salvageDebugInfo()`: ``` Core was generated by `/usr/obj/share/dim/src/freebsd/clang600-import/amd64.amd64/tmp/usr/bin/cc -cc1 -'. Program terminated with signal SIGBUS, Bus error. #0 isInvalidated () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SDNodeDbgValue.h:115 115 bool isInvalidated() const { return Invalid; } (gdb) bt #0 isInvalidated () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SDNodeDbgValue.h:115 #1 salvageDebugInfo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7116 #2 0x00000000033b2516 in operator() () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3595 #3 __invoke<(lambda at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3593:59) &, llvm::SDNode *, llvm::SDNode *> () at /usr/include/c++/v1/type_traits:4323 #4 __call<(lambda at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3593:59) &, llvm::SDNode *, llvm::SDNode *> () at /usr/include/c++/v1/__functional_base:349 #5 operator() () at /usr/include/c++/v1/functional:1562 #6 0x00000000033b0817 in operator() () at /usr/include/c++/v1/functional:1916 #7 NodeDeleted () at /share/dim/src/freebsd/clang600-import/contrib/llvm/include/llvm/CodeGen/SelectionDAG.h:293 #8 0x0000000003529dde in RemoveDeadNodes () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:610 #9 0x00000000035556df in MorphNodeTo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:6794 #10 0x00000000033a9acc in MorphNode () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2594 #11 0x00000000033ac80b in SelectCodeCommon () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3601 #12 0x00000000023d464b in SelectCode () at /usr/obj/share/dim/src/freebsd/clang600-import/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/X86GenDAGISel.inc:282902 #13 Select () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072 #14 0x00000000033a5afa in DoInstructionSelection () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:988 #15 0x00000000033a4e1a in CodeGenAndEmitDAG () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:868 #16 0x00000000033a2643 in SelectAllBasicBlocks () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1624 #17 0x000000000339f158 in runOnMachineFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:466 #18 0x00000000023d03c4 in runOnMachineFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:175 #19 0x00000000035cc8c2 in runOnFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/MachineFunctionPass.cpp:62 #20 0x00000000030dca9a in runOnFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1520 #21 0x00000000030dccf3 in runOnModule () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1541 #22 0x00000000030dd228 in runOnModule () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1597 #23 run () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1700 #24 0x00000000014db578 in EmitAssembly () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:815 #25 EmitBackendOutput () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1181 #26 0x00000000014d5b26 in HandleTranslationUnit () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:292 #27 0x0000000001c4c332 in ParseAST () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Parse/ParseAST.cpp:159 #28 0x00000000015d546c in Execute () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:897 #29 0x0000000001cec311 in ExecuteAction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:991 #30 0x00000000014b4f81 in ExecuteCompilerInvocation () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252 #31 0x00000000014aa73f in cc1_main () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:221 #32 0x00000000014b2928 in ExecuteCC1Tool () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/driver.cpp:309 #33 main () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/driver.cpp:388 (gdb) frame 1 #1 salvageDebugInfo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7116 7116 if (DV->isInvalidated()) (gdb) disassemble Dump of assembler code for function salvageDebugInfo(): [...] 0x0000000003557348 <+744>: nopl 0x0(%rax,%rax,1) 0x0000000003557350 <+752>: mov (%r12),%r13 => 0x0000000003557354 <+756>: cmpb $0x0,0x31(%r13) 0x0000000003557359 <+761>: jne 0x35573b0 <salvageDebugInfo()+848> (gdb) info registers [...] r13 0x5a5a5a5a5a5a5a5a 6510615555426900570 ``` The `0x5a5a5a5a5a5a5a5a` value in `r13` indicates the memory was either uninitialized, or already freed. Unfortunately I do not have a simple self-contained test case for this. However, it seems pretty clear that the call to `AddDbgValue()` in `salvageDebugInfo()` causes the problems, since it modifies `SelectionDag::DbgInfo` while looping through one of its DenseMaps: ``` void SelectionDAG::salvageDebugInfo(SDNode &N) { [...] for (auto DV : GetDbgValues(&N)) { if (DV->isInvalidated()) continue; [...] AddDbgValue(Clone, N0.getNode(), false); [...] } } ``` At least, if I comment out the `AddDbgValue()` call, the crashes go away. I propose to change this function slightly, similar to the `SelectionDAG::transferDbgValues()` function just above it, to save the cloned SDDbgValues in a separate SmallVector, and only call AddDbgValue() on them after the for loop is done. Reviewers: aprantl, bogner, bkramer, davide Reviewed By: davide Subscribers: davide, krytarowski, JDevlieghere, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D41589 llvm-svn: 321545
* [SelectionDAG] Add creating new node debug messages for load, store, gather, ↵Craig Topper2017-12-281-8/+24
| | | | | | and scatter. llvm-svn: 321540
* [SelectionDAG] Add some debug print messages to LegalizeVectorOps.Craig Topper2017-12-281-2/+15
| | | | llvm-svn: 321535
* [DAGCombine] foldBinOpIntoSelect can fail to constant fold in some cases.Simon Pilgrim2017-12-271-6/+8
| | | | | | | | For example, float operations may fail to constant fold under certain circumstances (inf/nan/denormal creation etc.) Reduced from oss-fuzz #4802 test case llvm-svn: 321488
* [DAGCombine] visitANDLike - ensure APInt is is in range for ↵Simon Pilgrim2017-12-261-4/+7
| | | | | | | | getSExtValue/getZExtValue Reduced from oss-fuzz #4782 test case llvm-svn: 321464
* [DAGCombine] Don't combine (and (setne X, 0), (setne X, -1)) --> (setuge ↵Simon Pilgrim2017-12-261-1/+2
| | | | | | | | (add X, 1), 2) for i1 Reduced from oss-fuzz #4773 test case llvm-svn: 321455
* [DAGCombiners] Don't turn ANDs to shuffles with zero so early. Give some ↵Craig Topper2017-12-241-7/+8
| | | | | | | | other combines a chance to run. This moves the combine for turning ANDs into shuffle with zero out of SimplifyVBinOps and places it only in visitAND below the reassociate handling. This fixes the specific case I noticed where we failed to combine two ands with constants. llvm-svn: 321417
* [SelectionDAG] Teach SelectionDAG::getNode to constant fold zext/aext/sext ↵Craig Topper2017-12-231-0/+3
| | | | | | of constant build vectors. llvm-svn: 321414
* [SelectionDAG][X86] Don't use ->getValueType(0) after a call to getOperand ↵Craig Topper2017-12-233-7/+7
| | | | | | | | | | to get the type of the operand. getOperand returns an SDValue that contains the node and the result number. There is no guarantee that the result number if 0. By using the -> operator we are calling SDNode::getValueType rather than SDValue::getValueType. This requires supplying a result number and we shouldn't assume it was 0. I don't have a test case. Just noticed while cleaning up some other code and saw that it occurred in other places. llvm-svn: 321397
* [DAG] Add missing case check from findbaseoffset merge from r321389.Nirav Dave2017-12-221-2/+4
| | | | llvm-svn: 321391
* Integrate findBaseOffset address analyses to BaseIndexOffset. NFCI.Nirav Dave2017-12-222-70/+27
| | | | | | | | | BaseIndexOffset supercedes findBaseOffset analysis save only Constant Pool addresses. Migrate analysis to BaseIndexOffset. Relanding after correcting base address matching check. llvm-svn: 321389
* Revert "[DAG] Integrate findBaseOffset address analyses to BaseIndexOffset. ↵Nirav Dave2017-12-222-27/+70
| | | | | | | | | | NFCI." which was causing miscompilations in for some test-suite components. This reverts commit 3e9de9ff0f3162920a2a3cba51c7dc14b54b4d16. llvm-svn: 321380
* [SelectionDAG] Reverse the order of operands in the ISD::ADD created by ↵Craig Topper2017-12-221-1/+1
| | | | | | | | | | TargetLowering::getVectorElementPointer so that the FrameIndex is on the left. This seems to improve X86's ability to match this into an address computation. Otherwise the other operand gets assigned to the base register and the stack pointer + frame index ends up in the index register. But index registers can't encode ESP/RSP so we end up having to move it into another register to meet the constraint. I could try to improve the address matcher in X86, but swapping the producer seemed easier. Several other places already have the operands in this order so this is at least consistent. llvm-svn: 321370
* [DAG] Integrate findBaseOffset address analyses to BaseIndexOffset. NFCI.Nirav Dave2017-12-222-70/+27
| | | | | | | BaseIndexOffset supercedes findBaseOffset analysis save only Constant Pool addresses. Migrate analysis to BaseIndexOffset. llvm-svn: 321364
* [DAGCombine] Revert r321259Sam Parker2017-12-221-26/+0
| | | | | | | Improve ReduceLoadWidth for SRL Patch is causing an issue on the PPC64 BE santizer. llvm-svn: 321349
* [DAGCombiner] Remove (xor (xor x, c1), c2) -> (xor x, (xor c1, c2)) fold. NFCI.Simon Pilgrim2017-12-211-15/+0
| | | | | | More general cases are already handled by constant canonicalization and then the ReassociateOps call at line 5327 llvm-svn: 321280
* [DAGCombiner] Generalize (or (and X, c1), c2) -> (and (or X, c2), c1|c2) ↵Simon Pilgrim2017-12-211-10/+10
| | | | | | | | combine to work on non-splat vectors The knownbits_mask_or_shuffle_uitofp change is interesting - shuffle combines manage to kick in, removing the AND constant mask load. For targets with fast-variable-shuffle this should reduce further to VPOR+VPSHUFB+VCVTDQ2PS. llvm-svn: 321279
* [DAGCombiner] Generalize (and (or x, C), D) -> D iff (C & D) == D combine to ↵Simon Pilgrim2017-12-211-4/+6
| | | | | | work on non-splat vectors llvm-svn: 321275
* [DAGCombine] Improve ReduceLoadWidth for SRLSam Parker2017-12-211-0/+26
| | | | | | | | | | | If the SRL node is only used by an AND, we may be able to set the ExtVT to the width of the mask, making the AND redundant. To support this, another check has been added in isLegalNarrowLoad which queries whether the load is valid. Differential Revision: https://reviews.llvm.org/D41350 llvm-svn: 321259
* DAG: Tolerate non-MemSDNodes for OPC_RecordMemRefMatt Arsenault2017-12-201-8/+24
| | | | | | | | | | | | | | | | | | | | When intrinsics are allowed to have mem operands, there are two ways this can happen. First is an intrinsic that is marked has having a mem operand, but is not handled by getTgtMemIntrinsic. The second way can occur even for intrinsics which do not have a mem operand. It seems the selector table does some kind of sorting based on the opcode, and the mem ref recording can happen in the same scope for intrinsics that both do and do not have mem refs. I haven't been able to figure out exactly why this happens (although it happens even with the matcher optimizations disabled). I'm not sure if it's worth trying to avoid hitting this for these nodes since I think it's still reasonable to handle this in case getTgtMemIntrinic is not implemented. llvm-svn: 321208
* [DAG] Fix condition on overlapping store check.Nirav Dave2017-12-201-2/+2
| | | | | | | Prevent overlapping store elision when overlapping store is pre-inc/dec as analysis is wrong in these cases. llvm-svn: 321204
* Add optional SelectionDAG* parameter to SValue::dump and SDValue::dumprKrzysztof Parzyszek2017-12-201-4/+4
| | | | | | | | | These functions simply call their counterparts in the associated SDNode, which do take an optional SelectionDAG. This change makes the legalization debug trace a little easier to read, since target-specific nodes will now have their names shown instead of "Unknown node #123". llvm-svn: 321180
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-192-1/+2
| | | | llvm-svn: 321114
* [DAG] Elide overlapping storeNirav Dave2017-12-191-21/+21
| | | | | | | | | | | | | | | | | Summary: Extend overlapping store elision to handle overwrites of stores by larger stores. Nontemporal tests have been modified to add memory dependencies to prevent store elision. Reviewers: craig.topper, rnk, t.p.northover Subscribers: javed.absar, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D40969 llvm-svn: 321089
OpenPOWER on IntegriCloud