summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-land "Fix faulty assertion in debug info"Adrian McCarthy2018-01-052-2/+4
| | | | | | | | | | | | This had been reverted because the new test failed on non-X86 bots. I moved the new test to the appropriate subdirectory to correct this. Differential Revision: https://reviews.llvm.org/D41264 Original submission: r321122 (which was reverted by r321125) This reverts commit 3c1639b5703c387a0d8cba2862803b4e68dff436. llvm-svn: 321911
* [DebugInfo] Align comments in debug_loc sectionBjorn Pettersson2018-01-051-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit updates the BufferByteStreamer, used by DebugLocStream to buffer bytes/comments to put in the debug_loc section, to make sure that the Buffer and Comments vectors are synced. Previously, when an SLEB128 or ULEB128 was emitted together with a comment, the vectors could be out-of-sync if the LEB encoding added several entries to the Buffer vectors, while we only added a single entry to the Comments vector. The goal with this is to get the comments in the debug_loc section in the .s file correctly aligned. Example (using ARM as target): Instead of .byte 144 @ sub-register DW_OP_regx .byte 128 @ 256 .byte 2 @ DW_OP_piece .byte 147 @ 8 .byte 8 @ sub-register DW_OP_regx .byte 144 @ 257 .byte 129 @ DW_OP_piece .byte 2 @ 8 .byte 147 @ .byte 8 @ we now get .byte 144 @ sub-register DW_OP_regx .byte 128 @ 256 .byte 2 @ .byte 147 @ DW_OP_piece .byte 8 @ 8 .byte 144 @ sub-register DW_OP_regx .byte 129 @ 257 .byte 2 @ .byte 147 @ DW_OP_piece .byte 8 @ 8 Reviewers: JDevlieghere, rnk, aprantl Reviewed By: aprantl Subscribers: davide, Ka-Ka, uabelho, aemerson, javed.absar, kristof.beyls, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41763 llvm-svn: 321907
* [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
* [GISel]: Don't create G_MUL with 1 during translation of GEPAditya Nandakumar2018-01-051-7/+12
| | | | | | | When element size is 1, it's just wasteful to create MUL with 1. https://reviews.llvm.org/D41738 llvm-svn: 321857
* Debug Info: Support DW_AT_calling_convention on composite types.Adrian Prantl2018-01-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the DWARF 5 feature described at http://www.dwarfstd.org/ShowIssue.php?issue=141215.1 This allows a consumer to understand whether a composite data type is trivially copyable and thus should be passed by value instead of by reference. The canonical example is being able to distinguish the following two types: // S is not trivially copyable because of the explicit destructor. struct S { ~S() {} }; // T is a POD type. struct T { ~T() = default; }; This patch adds two new (DI)flags to LLVM metadata: TypePassByValue and TypePassByReference. <rdar://problem/36034922> Differential Revision: https://reviews.llvm.org/D41743 llvm-svn: 321844
* [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
* Changes in the branch relaxation algorithm.Elena Demikhovsky2018-01-041-57/+107
| | | | | | | | | The existing version worked incorrectly when inversion of a branch condintion is impossible. Changed the "fixupConditionalBranch()" function - a new BB (a trampoline) is created to keep the original branch condition. Differential Revision: https://reviews.llvm.org/D41634 llvm-svn: 321785
* support phi ranges for machine-level IRBob Wilson2018-01-041-16/+10
| | | | | | | | | | | | Add iterator ranges for machine instruction phis, similar to the IR-level phi ranges added in r303964. I updated a few places to use this. Besides general code simplification, this change will allow removing a non-upstream change from Swift's copy of LLVM (in a better way than my previous attempt in http://reviews.llvm.org/D19080). https://reviews.llvm.org/D41672 llvm-svn: 321783
* [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
* [ExpandMemcmp] rename variables and add hook to override pref for number of ↵Sanjay Patel2018-01-031-14/+17
| | | | | | | | | | | loads per block; NFC The preference only applies to 'memcmp() == 0' expansion, so try to make that clearer. x86 will likely benefit by increasing the default value from '1' to '2' as seen in PR33325: https://bugs.llvm.org/show_bug.cgi?id=33325 ...so that is the planned follow-up to this clean-up step. llvm-svn: 321756
* Thread MCSubtargetInfo through Target::createMCAsmBackendAlex Bradbury2018-01-031-7/+4
| | | | | | | | | | | | | | | | | | | | | Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. D20830 threaded an MCSubtargetInfo reference through MCAsmBackend::relaxInstruction, but this isn't the only function that would benefit from access. This patch removes the Triple and CPUString arguments from createMCAsmBackend and replaces them with MCSubtargetInfo. This patch just changes the interface without making any intentional functional changes. Once in, several cleanups are possible: * Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend * Support 16-bit instructions when valid in MipsAsmBackend::writeNopData * Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl * Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221) This change initially exposed PR35686, which has since been resolved in r321026. Differential Revision: https://reviews.llvm.org/D41349 llvm-svn: 321692
* [GlobalISel][Legalizer] Fix legalization of llvm.smul.with.overflowAmara Emerson2018-01-031-1/+15
| | | | | | | | | Previously the code for handling G_SMULO didn't properly check for the signed multiply overflow, instead treating it the same as the unsigned G_UMULO. Fixes PR35800. llvm-svn: 321690
* [AArch64][GlobalISel] Fix assert fail with unknown intrinsic.Amara Emerson2018-01-021-5/+8
| | | | | | | | A call may have an intrinsic name but not have a valid intrinsic ID, for example with llvm.invariant.group.barrier. If so, treat it as a normal call like FastISel does. llvm-svn: 321662
* [AArch64][GlobalISel] Enable GlobalISel at -O0 by defaultAmara Emerson2018-01-021-2/+10
| | | | | | | | | | | Tests updated to explicitly use fast-isel at -O0 instead of implicitly. This change also allows an explicit -fast-isel option to override an implicitly enabled global-isel. Otherwise -fast-isel would have no effect at -O0. Differential Revision: https://reviews.llvm.org/D41362 llvm-svn: 321655
* 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-306-81/+51
| | | | llvm-svn: 321585
* [MachineOperand] Fix LiveDebugVariables code after isRenamable change.Geoff Berry2017-12-291-1/+4
| | | | | | | | | | | Fix code in LiveDebugVariables that was changing def MachineOperands to uses, which will hit an assert for dead operands after the change to add the renamable bit to MachineOperands. Avoid the assert by clearing the dead bit before changing the operand to a use. Fixes issue reported in out of tree target by Jesper Antonsson at Ericsson. llvm-svn: 321571
* 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
* (Re-landing) Expose a TargetMachine::getTargetTransformInfo functionSanjoy Das2017-12-221-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-land r321234. It had to be reverted because it broke the shared library build. The shared library build broke because there was a missing LLVMBuild dependency from lib/Passes (which calls TargetMachine::getTargetIRAnalysis) to lib/Target. As far as I can tell, this problem was always there but was somehow masked before (perhaps because TargetMachine::getTargetIRAnalysis was a virtual function). Original commit message: This makes the TargetMachine interface a bit simpler. We still need the std::function in TargetIRAnalysis to avoid having to add a dependency from Analysis to Target. See discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html I avoided adding all of the backend owners to this review since the change is simple, but let me know if you feel differently about this. Reviewers: echristo, MatzeB, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D41464 llvm-svn: 321375
* [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
* Add hasProfileData() to check if a function has profile data. NFC.Easwaran Raman2017-12-221-3/+3
| | | | | | | | | | | | | | | | | | | Summary: This replaces calls to getEntryCount().hasValue() with hasProfileData that does the same thing. This refactoring is useful to do before adding synthetic function entry counts but also a useful cleanup IMO even otherwise. I have used hasProfileData instead of hasRealProfileData as David had earlier suggested since I think profile implies "real" and I use the phrase "synthetic entry count" and not "synthetic profile count" but I am fine calling it hasRealProfileData if you prefer. Reviewers: davidxl, silvas Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41461 llvm-svn: 321331
* [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
* Revert "Expose a TargetMachine::getTargetTransformInfo function"Sanjoy Das2017-12-211-3/+4
| | | | | | This reverts commit r321234. It breaks the -DBUILD_SHARED_LIBS=ON build. llvm-svn: 321243
* Expose a TargetMachine::getTargetTransformInfo functionSanjoy Das2017-12-211-4/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This makes the TargetMachine interface a bit simpler. We still need the std::function in TargetIRAnalysis to avoid having to add a dependency from Analysis to Target. See discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html I avoided adding all of the backend owners to this review since the change is simple, but let me know if you feel differently about this. Reviewers: echristo, MatzeB, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D41464 llvm-svn: 321234
* 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
* [PGO] Function section hotness prefix should look at all blocksTeresa Johnson2017-12-201-11/+4
| | | | | | | | | | | | | | | | | | | | Summary: The function section prefix for PGO based layout (e.g. hot/unlikely) should look at the hotness of all blocks not just the entry BB. A function with a cold entry but a very hot loop should be placed in the hot section, for example, so that it is located close to other hot functions it may call. For SamplePGO it was already looking at the branch weights on calls, and I made that code conditional on whether this is SamplePGO since it was essentially a noop for instrumentation PGO anyway. Reviewers: davidxl Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D41395 llvm-svn: 321197
* 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
* Revert "Fix faulty assertion in debug info"Adrian McCarthy2017-12-192-4/+2
| | | | | | This reverts commit e32def3f7ebe1136b7038336eff56a415a962bf2. llvm-svn: 321125
* Fix faulty assertion in debug infoAdrian McCarthy2017-12-192-2/+4
| | | | | | | | | | | | | | It appears the code uses nullptr to represent a void type in debug metadata, which led to an assertion failure when building DeltaAlgorithm.cpp with a self-hosted clang on Windows. I'm not sure why/if the problem was Windows-specific. Fixes bug https://bugs.llvm.org/show_bug.cgi?id=35543 Differential Revision: https://reviews.llvm.org/D41264 llvm-svn: 321122
OpenPOWER on IntegriCloud