summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r354498 "[X86] Add test case to show missed opportunity to remove an ↵Craig Topper2019-02-201-7/+3
| | | | | | | | explicit AND on the bit position from BT when it has known zeros." I accidentally committed more than just the test. llvm-svn: 354499
* [X86] Add test case to show missed opportunity to remove an explicit AND on ↵Craig Topper2019-02-201-3/+7
| | | | | | | | | | the bit position from BT when it has known zeros. If the bit position has known zeros in it, then the AND immediate will likely be optimized to remove bits. This can prevent GetDemandedBits from recognizing that the AND is unnecessary. llvm-svn: 354498
* GlobalISel: Fix fewerElementsVector for ctlz with different result typeMatt Arsenault2019-02-201-1/+5
| | | | | | Also complete the set of related operations. llvm-svn: 354480
* GlobalISel: Implement moreElementsVector for g_insert resultsMatt Arsenault2019-02-201-0/+8
| | | | llvm-svn: 354477
* Re-land the refactoring part of r354244 "[DAGCombiner] Eliminate dead stores ↵Clement Courbet2019-02-202-35/+80
| | | | | | | | to stack." This is an NFC. llvm-svn: 354476
* [Codegen] Remove dead flags on Physical Defs in machine cseDavid Green2019-02-201-19/+24
| | | | | | | | | | We may leave behind incorrect dead flags on instructions that are CSE'd. Make sure we remove the dead flags on physical registers to prevent other incorrect code motion. Differential Revision: https://reviews.llvm.org/D58115 llvm-svn: 354443
* [RegAllocGreedy] Take last chance recoloring into account in split and assignMikael Holmen2019-02-201-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to r353988 where tryEvict was extended to take last chance recoloring into account. Now we do the same thing for trySplit and tryAssign. Now we always pass a "FixedRegisters" argument to canEvictInterference and tryEvict so it doesn't need to have a default value anymore. The need for this was found long ago in an out-of-tree target. Unfortunately I don't have a reproducer for an in-tree target. Reviewers: qcolombet, rudkx Reviewed By: qcolombet, rudkx Subscribers: rudkx, MatzeB, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58376 llvm-svn: 354439
* [NFC] add/modify wrapper function for findRegisterDefOperand().Chen Zheng2019-02-203-3/+4
| | | | llvm-svn: 354438
* [WebAssembly] Update MC for bulk memoryThomas Lively2019-02-191-3/+14
| | | | | | | | | | | | | | | | | | Summary: Rename MemoryIndex to InitFlags and implement logic for determining data segment layout in ObjectYAML and MC. Also adds a "passive" flag for the .section assembler directive although this cannot be assembled yet because the assembler does not support data sections. Reviewers: sbc100, aardappel, aheejin, dschuff Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57938 llvm-svn: 354397
* [SDAG] Use shift amount type in MULO promotion; NFCNikita Popov2019-02-191-2/+4
| | | | | | | | | | Directly use the correct shift amount type if it is possible, and future-proof the code against vectors. The added test makes sure that bitwidths that do not fit into the shift amount type do not assert. Split out from D57997. llvm-svn: 354359
* GlobalISel: Implement moreElementsVector for selectMatt Arsenault2019-02-191-0/+12
| | | | llvm-svn: 354354
* GlobalISel: Implement moreElementsVector for G_EXTRACT sourceMatt Arsenault2019-02-191-0/+7
| | | | llvm-svn: 354348
* GlobalISel: Implement moreElementsVector for bit opsMatt Arsenault2019-02-191-0/+40
| | | | llvm-svn: 354345
* GlobalISel: Verify g_insertMatt Arsenault2019-02-191-0/+24
| | | | llvm-svn: 354342
* [GlobalISel][AArch64] Legalize + select some llvm.ctlz.* intrinsicsJessica Paquette2019-02-181-0/+1
| | | | | | | | | | | | Legalize/select llvm.ctlz.* Add select-ctlz to show that we actually select them. Update arm64-clrsb.ll and arm64-vclz.ll to show that we perform valid transformations in optimized builds, and document where GISel can improve. Differential Revision: https://reviews.llvm.org/D58155 llvm-svn: 354299
* [CGP] form usub with overflow from sub+icmpSanjay Patel2019-02-181-13/+78
| | | | | | | | | | | | | | | | | The motivating x86 cases for forming the intrinsic are shown in PR31754 and PR40487: https://bugs.llvm.org/show_bug.cgi?id=31754 https://bugs.llvm.org/show_bug.cgi?id=40487 ..and those are shown in the IR test file and x86 codegen file. Matching the usubo pattern is harder than uaddo because we have 2 independent values rather than a def-use. This adds a TLI hook that should preserve the existing behavior for uaddo formation, but disables usubo formation by default. Only x86 overrides that setting for now although other targets will likely benefit by forming usbuo too. Differential Revision: https://reviews.llvm.org/D57789 llvm-svn: 354298
* GlobalISel: Implement widenScalar for g_extract scalar resultsMatt Arsenault2019-02-181-6/+48
| | | | llvm-svn: 354293
* GlobalISel: Make buildExtract use DstOp/SrcOpMatt Arsenault2019-02-181-12/+15
| | | | llvm-svn: 354292
* GlobalISel: Fix double count of offset for irregular vector breakdownsMatt Arsenault2019-02-181-1/+0
| | | | | | | Fixes cases with odd vectors that break into multiple requested size pieces. llvm-svn: 354280
* Revert r354244 "[DAGCombiner] Eliminate dead stores to stack."Clement Courbet2019-02-185-209/+45
| | | | | | Breaks some bots. llvm-svn: 354245
* [DAGCombiner] Eliminate dead stores to stack.Clement Courbet2019-02-185-45/+209
| | | | | | | | | | | | | | | Summary: A store to an object whose lifetime is about to end can be removed. See PR40550 for motivation. Reviewers: niravd Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57541 llvm-svn: 354244
* [SelectionDAG] Extract [US]MULO expansion into TL method; NFCNikita Popov2019-02-172-148/+124
| | | | | | | | | | | | In preparation for supporting vector expansion. Add an isPostTypeLegalization flag to makeLibCall(), because this expansion relies on the legalized form using MERGE_VALUES. Drop the corresponding variant of ExpandLibCall, which is no longer used. Differential Revision: https://reviews.llvm.org/D58006 llvm-svn: 354226
* [X86] Fix LowerAsmOutputForConstraint.Nirav Dave2019-02-152-3/+2
| | | | | | | | | | | | | | | | | Summary: Update Flag when generating cc output. Fixes PR40737. Reviewers: rnk, nickdesaulniers, craig.topper, spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58283 llvm-svn: 354163
* Fix 80-column limit in SimplifyDemandedBits/SimplifyDemandedVectorElts. NFCI.Simon Pilgrim2019-02-151-70/+78
| | | | llvm-svn: 354152
* GlobalISel: Fix inadequate verification of g_build_vectorMatt Arsenault2019-02-151-6/+11
| | | | | | | | | | | | | Testing based on the total size of the elements failed to catch a few invalid scenarios, so explicitly check the number of elements/operands and types. This failed to catch situations like <4 x s16> = G_BUILD_VECTOR s32, s32 since the total size added up. This also would fail to catch an implicit conversion between pointers and scalars. llvm-svn: 354139
* [GISel][NFC]: Add methods to speed up insertion into GISelWorklistAditya Nandakumar2019-02-152-3/+6
| | | | | | | | | | | | | https://reviews.llvm.org/D58073 Speed up insertion during the initial populating phase into the GISelWorkList by deferring repeatedly resizing the DenseMap. This results in ~10% improvement in the combiner passes, and ~3% speedup in the Legalizer. reviewed by: aemerson. llvm-svn: 354093
* GlobalISel: Add alignment to LegalityQuery MMOsMatt Arsenault2019-02-142-10/+15
| | | | | | | This allows targets to specify the minimum alignment required for the load/store. llvm-svn: 354071
* [MIPS GlobalISel] Select branch instructionsPetar Avramovic2019-02-141-1/+1
| | | | | | | | | | | | | Select G_BR and G_BRCOND for MIPS32. Unconditional branch G_BR does not have register operand, for that reason we only add tests. Since conditional branch G_BRCOND compares register to zero on MIPS32, explicit extension must be performed on i1 condition in order to set high bits to appropriate value. Differential Revision: https://reviews.llvm.org/D58182 llvm-svn: 354022
* Fix an accidentally flipped pair of arguments, NFCIJeremy Morse2019-02-141-1/+1
| | | | | | | | | While rebasing a refactor in r353950 I accidentally swapped two function arguments; one is SelectionDAGBuilders "current" DebugLoc, the other is the one from the "current" debug intrinsic. They're probably always identical, but I haven't proved that yet. llvm-svn: 354019
* [globalisel][combine] Split existing rules into a match and apply stepDaniel Sanders2019-02-141-21/+39
| | | | | | | | | | | | | | | | | | | Summary: The declarative tablegen definitions split rules into match and apply steps. Prepare for that by doing the same in the C++ implementations. This aids some of the migration effort while the tablegen version is incomplete. Reviewers: bogner, volkan, aditya_nandakumar, paquette, aemerson Reviewed By: aditya_nandakumar Subscribers: rovka, kristof.beyls, Petar.Avramovic, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58150 llvm-svn: 353996
* [SelectionDAG] Inline a single use helper function, and remove last non-MMO ↵Philip Reames2019-02-132-33/+22
| | | | | | | | interface [NFC] For D57601, we need to know whether the instruction is volatile. We'd either have to pass yet another parameter, or just standardize on the MMO interface. I chose the second. llvm-svn: 353989
* [RegAllocGreedy] Take last chance recoloring into account in evicting.Mark Lacey2019-02-131-6/+20
| | | | | | | | | | | | | | | | | | | | | | Last chance recoloring inserts into FixedRegisters those virtual registers it is attempting to assign a physical register to. We must consider these when we consider candidates for eviction so that we do not end up evicting something while we are attempting to recolor to assign it. This is hitting in an out-of-tree target and no longer reproduces on trunk. That does not appear to be a result of it having been fixed, but rather, it appears that optimization changes and/or other changes to register allocation mask the problem. I haven't found a way to come up with a reasonable test case for this (i.e. one that I can actually commit to open source, is reasonable in size, and actually reproduces the issue). rdar://problem/45708741 llvm-svn: 353988
* [SelectionDAG] Kill last uses of getAtomic w/o a MMO operand [NFC]Philip Reames2019-02-132-44/+36
| | | | | | The helper function was used by only two callers, and largely ended up providing distinct functionality based on optional arguments and opcode. Inline and simply to make the functionality much more clear. llvm-svn: 353977
* [DebugInfo][DAG] Either salvage dangling debug info or emit Undef DBG_VALUEsJeremy Morse2019-02-133-19/+96
| | | | | | | | | | | | | | | | | | | | | | | | | In this patch SelectionDAG tries to salvage any dbg.values that are going to be dropped, in case they can be recovered from Values in the current BB. It also strengthens SelectionDAGs handling of dangling debug data, so that dbg.values are *always* emitted (as Undef or otherwise) instead of dangling forever. The motivation behind this patch exists in the new test case: a memory address (here a bitcast and GEP) exist in one basic block, and a dbg.value referring to the address is left in the 'next' block. The base pointer is live across all basic blocks. In current llvm trunk the dbg.value cannot be encoded, and it isn't even emitted as an Undef DBG_VALUE. The change is simply: if we're definitely going to drop a dbg.value, repeatedly apply salvageDebugInfo to its operand until either we find something that can be encoded, or we can't salvage any further in which case we produce an Undef DBG_VALUE. To know when we're "definitely going to drop a dbg.value", SelectionDAG signals SelectionDAGBuilder when all IR instructions have been encoded to force salvaging. This ensures that any dbg.value that's dangling after DAG creation will have a corresponding DBG_VALUE encoded. Differential Revision: https://reviews.llvm.org/D57694 llvm-svn: 353954
* [DebugInfo][DAG] Refactor dbg.value lowering into its own methodJeremy Morse2019-02-132-84/+100
| | | | | | | | | | This is a pure copy-and-paste job, moving the logic for lowering dbg.value intrinsics to SDDbgValues into its own function. This is ahead of adding some more users of this logic. Differential Revision: https://reviews.llvm.org/D57697 llvm-svn: 353950
* [DebugInfo][DAG] Limit special-casing of dbg.values for ArgumentsJeremy Morse2019-02-131-4/+10
| | | | | | | | | | | | | | | | | | | | | SelectionDAGBuilder has special handling for dbg.value intrinsics that are understood to define the location of function parameters on entry to the function. To enable this, we avoid recording a dbg.value as a virtual register reference if it might be such a parameter, so that it later hits EmitFuncArgumentDbgValue. This patch reduces the set of circumstances where we avoid recording a dbg.value as a virtual register reference, to allow more "normal" variables to be recorded that way. We now only bypass for potential parameters if: * The dbg.value operand is an Argument, * The Variable is a parameter, and * The Variable is not inlined. meaning it's very likely that the dbg.value is a function-entry parameter location. Differential Revision: https://reviews.llvm.org/D57584 llvm-svn: 353948
* [DebugInfo] Stop changing labels for register-described parameter DBG_VALUEsDavid Stenberg2019-02-131-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D57510. This patch stops DebugHandlerBase from changing the starting label for the first non-overlapping, register-described parameter DBG_VALUEs to the beginning of the function. That code did not consider what defined the registers, which could result in the ranges for the debug values starting before their defining instructions. We currently do not emit debug values for constant values directly at the start of the function, so this code is still useful for such values, but my intention is to remove the code from DebugHandlerBase completely when we get there. One reason for removing it is that the code violates the history map's ranges, which I think can make it quite confusing when troubleshooting. In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs now are kept at the start of the entry block, even after emission of prologue code. That was done to reduce the degradation of debug completeness from this patch. PR40638 is another example, where the lexical-scope trimming that LDV does, in combination with scheduling, results in instructions after the prologue being left without locations. There might be other cases where the DBG_VALUEs are pushed further down, for which the DebugHandlerBase code may be helpful, but as it now quite often result in incorrect locations, even after the prologue, it seems better to remove that code, and try to work our way up with accurate locations. In the long run we should maybe not aim to provide accurate locations inside the prologue. Some single location descriptions, at least those referring to stack values, generate inaccurate values inside the epilogue, so we maybe should not aim to achieve accuracy for location lists. However, it seems that we now emit line number programs that can result in GDB and LLDB stopping inside the prologue when doing line number stepping into functions. See PR40188 for more information. A summary of some of the changed test cases is available in PR40188#c2. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D57511 llvm-svn: 353928
* [SelectionDAG] Clean up comments in SelectionDAGBuilder.h. NFCBjorn Pettersson2019-02-121-46/+42
| | | | | | | Remove redundant function/variable names from doxygen comments (as suggested in https://reviews.llvm.org/D57697). llvm-svn: 353886
* [InlineSpiller] Fix a crash due to lack of forward progress from remat (try 2)Philip Reames2019-02-121-0/+35
| | | | | | | | | | | This is a recommit of r335091 Add more test cases for deopt-operands via regalloc, and r335077 [InlineSpiller] Fix a crash due to lack of forward progress from remat specifically for STATEPOINT. They were reverted due to a crash. This change includes the text of both original changes, but also includes three aditional pieces: 1) A bug fix for the observed crash. I had failed to record the failed remat value as live which resulted in an instruction being deleted which still had uses. With the machine verifier, this is caught quickly. Without it, we fail in StackSlotColoring due to an empty live interval from LiveStack. 2) A test case which demonstrates the fix for (1). See @test11. 3) A control flag which defaults to disabling this for the moment. Once I've run more extensive validaton, I will switch the default and then remove this flag. llvm-svn: 353871
* [GlobalISel][NFC] Gardening: Make translateSimpleUnaryIntrinsic generalJessica Paquette2019-02-121-26/+18
| | | | | | | | | | | | | | Instead of only having this code work for unary intrinsics, have it work for an arbitrary number of parameters. Factor out the cases that fall under this (fma, pow). This makes it a bit easier to add more intrinsics which don't require any special work. Differential Revision: https://reviews.llvm.org/D58079 llvm-svn: 353863
* [GlobalISel][AArch64] Select llvm.bswap* for non-vector typesJessica Paquette2019-02-121-0/+2
| | | | | | | | | | | | | | | | This teaches the IRTranslator to emit G_BSWAP when it runs into Intrinsic::bswap. This allows us to select G_BSWAP for non-vector types in AArch64. Add a select-bswap.mir test, and add global isel checks to a couple existing tests in test/CodeGen/AArch64. This doesn't handle every bswap case, since some of these rely on known bits stuff. This just lets us handle the naive case. Differential Revision: https://reviews.llvm.org/D58081 llvm-svn: 353861
* [DAGCombiner] convert logic-of-setcc into bit magic (PR40611)Sanjay Patel2019-02-121-0/+26
| | | | | | | | | | | | | | | | | | | | If we're comparing some value for equality against 2 constants and those constants have an absolute difference of just 1 bit, then we can offset and mask off that 1 bit and reduce to a single compare against zero: and/or (setcc X, C0, ne), (setcc X, C1, ne/eq) --> setcc ((add X, -C1), ~(C0 - C1)), 0, ne/eq https://rise4fun.com/Alive/XslKj This transform is disabled by default using a TLI hook ("convertSetCCLogicToBitwiseLogic()"). That should be overridden for AArch64, MIPS, Sparc and possibly others based on the asm shown in: https://bugs.llvm.org/show_bug.cgi?id=40611 llvm-svn: 353859
* [SelectionDAG] Fix return calling convention in expansion of ?MULOwhitequark2019-02-121-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The SMULO/UMULO DAG nodes, when not directly supported by the target, expand to a multiplication twice as wide. In case that the resulting type is not legal, the legalizer cannot directly call the intrinsic with the wide arguments; instead, it "pre-lowers" them by splitting them in halves. rL283203 made sure that on big endian targets, the legalizer passes the argument halves in the correct order. It did not do the same for the return value halves because the existing code used a hack; it put an illegal type into DAG and hoped that nothing would break and it would be correctly lowered elsewhere. rL307207 fixed this, handling return value halves similar to how argument handles are handled, but did not take big-endian targets into account. This commit fixes the expansion on big-endian targets, such as the out-of-tree OR1K target. Reviewers: eli.friedman, vadimcn Subscribers: george-hopkins, efriedma, llvm-commits Differential Revision: https://reviews.llvm.org/D45355 llvm-svn: 353854
* [Codegen] Make sure kill flags are not incorrect from removed machine phi'sDavid Green2019-02-121-3/+4
| | | | | | | | | We need to clear the kill flags on both SingleValReg and OldReg, to ensure they remain conservatively correct. Differential Revision: https://reviews.llvm.org/D58114 llvm-svn: 353847
* GlobalISel: Use default rounding mode when extending fconstantMatt Arsenault2019-02-121-3/+8
| | | | | | | I don't think this matters since the values should all be exactly representable. llvm-svn: 353844
* GlobalISel: Move some more legalize cases into functionsMatt Arsenault2019-02-121-165/+190
| | | | llvm-svn: 353843
* [DebugInfo] Keep parameter DBG_VALUEs before prologue codeDavid Stenberg2019-02-121-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory change for removing the code from DebugHandlerBase::beginFunction() which changes the starting label for the first non-overlapping DBG_VALUEs of parameters to the beginning of the function. It does that to be able to show parameters when entering a function. However, that code does not consider what defines the values, which can result in the ranges for the debug values starting before their defining instructions. That code is removed in a follow-up patch. When prologue code is inserted, it leads to DBG_VALUEs that start directly in the entry block being moved down after the prologue instructions. This patch fixes that by stashing away DBG_VALUEs for parameters before emitting the prologue, and then reinserts them at the start of the block. This assumes that there is no target that somehow clobbers parameter registers in the frame setup; there is no such case in the lit tests at least. See PR40188 for more information. Reviewers: aprantl, dblaikie, rnk, jmorse Reviewed By: aprantl Subscribers: bjope, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D57510 llvm-svn: 353823
* [Statepoint Lowering] Update misleading comments about chainsPhilip Reames2019-02-121-9/+7
| | | | llvm-svn: 353800
* DebugInfo: Split DWARF + gmlt + no-split-dwarf-inlining shouldn't emit ↵David Blaikie2019-02-122-2/+12
| | | | | | | | | | | | | | | anything to the .dwo file This configuration (due to r349207) was intended not to emit any DWO CU, but a degenerate CU was still being emitted - containing a header and a DW_TAG_compile_unit with no attributes. Under that situation, emit nothing to the .dwo file. (since this is a dynamic property of the input the .dwo file is still emitted, just with nothing in it (so a valid, but empty, ELF file) - if some other CU didn't satisfy this criteria, its DWO CU would still go there, etc) llvm-svn: 353771
* Be conservative about unordered accesses for the momentPhilip Reames2019-02-112-3/+8
| | | | | | | | | | Background: As described in https://reviews.llvm.org/D57601, I'm working towards separating volatile and atomic in the MMO uses for atomic instructions. In https://reviews.llvm.org/D57593, I fixed a bug where isUnordered was returning the wrong result, but didn't account for the fact I was getting slightly ahead of myself. While both uses of isUnordered are correct (as far as I can tell), we don't have tests to demonstrate this and being aggressive gets in the way of having the removal of volatile truly be non-functional. Once D57601 lands, I will return to these call sites, revert this patch, and add the appropriate tests to show the expected behaviour. Differential Revision: https://reviews.llvm.org/D57802 llvm-svn: 353766
OpenPOWER on IntegriCloud