summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/SelectionDAG
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [DAGCombine] Move AND nodes to multiple load leavesSam Parker2017-12-181-0/+144
| | | | | | | | | | | | | Search from AND nodes to find whether they can be propagated back to loads, so that the AND and load can be combined into a narrow load. We search through OR, XOR and other AND nodes and all bar one of the leaves are required to be loads or constants. The exception node then needs to be masked off meaning that the 'and' isn't removed, but the loads(s) are narrowed still. Differential Revision: https://reviews.llvm.org/D41177 llvm-svn: 320962
* Fix unused variable in non-assert buildsMatthias Braun2017-12-151-2/+1
| | | | llvm-svn: 320885
* MachineFunction: Return reference from getFunction(); NFCMatthias Braun2017-12-156-31/+29
| | | | | | The Function can never be nullptr so we can return a reference. llvm-svn: 320884
* [SelectionDAG][X86] Fix insert_vector_elt lowering for v32i1/v64i1 with ↵Craig Topper2017-12-151-4/+25
| | | | | | | | | | | | | | | | | | | | | | | non-constant index Summary: Currently we don't handle v32i1/v64i1 insert_vector_elt correctly as we fail to look at the number of elements closely and assume it can only be v16i1 or v8i1. We also can't type legalize v64i1 insert_vector_elt correctly on KNL due to the type not being byte addressable as required by the legalizing through memory accesses path requires. For the first issue, the patch now tries to pick a 512-bit register with the correct number of elements and promotes to that. For the second issue, we now extend the vector to a byte addressable type, do the stores to memory, load the two halves, and then truncate the halves back to the original type. Technically since we changed the type, we may not need two loads, but actually checking that is more work and for the v64i1 case we do need them. Reviewers: RKSimon, delena, spatel, zvi Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40942 llvm-svn: 320849
* [SelectionDAG] Make getNode calls that take an ArrayRef of SDValue for ↵Craig Topper2017-12-151-4/+7
| | | | | | | | | | operands call NewSDValueDbgMsg. This makes it work better with some build_vector and concat_vectors creations. Adjust the NewSDValueDbgMsg in getConstant to avoid duplicating the print when it calls getSplatBuildVector since getSplatBuildVector didn't trigger a print before. llvm-svn: 320783
* EmitFuncArgumentDbgValue: Prefer stack slots over registers for stack argumentsAdrian Prantl2017-12-141-7/+7
| | | | | | | | | | | | | | | | | | While investigating LLVM PR22316 (http://llvm.org/bugs/show_bug.cgi?id=22316) I started wondering if it were not always preferable to emit the initial DBG_VALUEs for stack arguments as FI locations instead of describing the first register they get copied into. The advantage of doing this is that the arguments will be available as soon as the stack is setup. As illustrated by the testcase in the PR, the first copy of the FI into a register may be sunk by MachineSink.cpp into a later basic block. By describing the argument on the stack, we nicely circumvent this problem. <rdar://problem/19583723> Differential Revision: https://reviews.llvm.org/D41135 llvm-svn: 320758
* TLI: Allow using PSV for intrinsic mem operandsMatt Arsenault2017-12-141-1/+3
| | | | llvm-svn: 320756
* Fix many -Wsign-compare and -Wtautological-constant-compare warnings.Zachary Turner2017-12-141-1/+1
| | | | | | | | | | | | Most of the -Wsign-compare warnings are due to the fact that enums are signed by default in the MS ABI, while the tautological comparison warnings trigger on x86 builds where sizeof(size_t) is 4 bytes, so N > numeric_limits<unsigned>::max() is always false. Differential Revision: https://reviews.llvm.org/D41256 llvm-svn: 320750
OpenPOWER on IntegriCloud