summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [DAGCombiner] Remove unnecessary recursive ↵Simon Pilgrim2018-12-101-6/+0
| | | | | | | | DAGCombiner::visitINSERT_SUBVECTOR call. As discussed on D55511, this caused an issue if the inner node deletes a node that the outer node depends upon. As it doesn't affect any lit-tests and I've only been able to expose this with the D55511 change I'm committing this now. llvm-svn: 348781
* [GlobalISel] Set stack protector index when translating ↵Petr Pavlu2018-12-101-5/+7
| | | | | | | | | | | | | | | | | | Intrinsic::stackprotector Record the stack protector index in MachineFrameInfo when translating Intrinsic::stackprotector similarly as is done by SelectionDAG when processing the same intrinsic. Setting this index allows the Prologue/Epilogue Insertion to recognize that the stack protection is enabled. The pass can then make sure that the stack protector comes before local variables on the stack and assigns potentially vulnerable objects first so they are close to the stack protector slot. Differential Revision: https://reviews.llvm.org/D55418 llvm-svn: 348761
* [DAGCombiner] Use the result value type in visitCONCAT_VECTORSFrancis Visoiu Mistrih2018-12-101-1/+1
| | | | | | | | | | | | | | | This triggers an assert when combining concat_vectors of a bitcast of merge_values. With asserts disabled, it fails to select: fatal error: error in backend: Cannot select: 0x7ff19d000e90: i32 = any_extend 0x7ff19d000ae8 0x7ff19d000ae8: f64,ch = CopyFromReg 0x7ff19d000c20:1, Register:f64 %1 0x7ff19d000b50: f64 = Register %1 In function: d Differential Revision: https://reviews.llvm.org/D55507 llvm-svn: 348759
* [DebugInfo] Don't drop dbg.value's of nullptrJeremy Morse2018-12-102-1/+5
| | | | | | | | | | | | | | | | | | | Currently, dbg.value's of "nullptr" are dropped when entering a SelectionDAG -- apparently just because of an oversight when recognising Values that are constant (see PR39787). This patch adds ConstantPointerNull to the list of constants that can be turned into DBG_VALUEs. The matter of what bit-value a null pointer constant in LLVM has was raised in this mailing list thread: http://lists.llvm.org/pipermail/llvm-dev/2018-December/128234.html Where it transpires LLVM relies on (IR) null pointers being zero valued, thus I've baked this assumption into the patch. Differential Revision: https://reviews.llvm.org/D55227 llvm-svn: 348753
* [DebugInfo] Emit undef DBG_VALUEs when SDNodes are optimised outJeremy Morse2018-12-105-11/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix for PR39896, where dbg.value's of SDNodes that have been optimised out do not lead to "DBG_VALUE undef" instructions being created. Such undef instructions are necessary to terminate earlier variable ranges, otherwise variable values leak past the point where they're valid. The "invalidated" flag of SDDbgValue is currently being abused to mean two things: * The corresponding SDNode is now invalid * This SDDbgValue should not be emitted Of which there are several legitimate combinations of meaning: * The SDNode has been invalidated and we should emit "DBG_VALUE undef" * The SDNode has been invalidated but the debug data was salvaged, don't emit anything for this SDDbgValue * This SDDbgValue has been emitted This patch introduces distinct "Emitted" and "Invalidated" fields to the SDDbgValue class, updates users accordingly, and generates "undef" DBG_VALUEs for invalidated records. Awkwardly, there are circumstances where we emit SDDbgValue's twice, specifically DebugInfo/X86/dbg-addr-dse.ll which I've preserved. Differential Revision: https://reviews.llvm.org/D55372 llvm-svn: 348751
* [DAGCombiner] re-enable truncation of binopsSanjay Patel2018-12-081-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is effectively re-committing the changes from: rL347917 (D54640) rL348195 (D55126) ...which were effectively reverted here: rL348604 ...because the code had a bug that could induce infinite looping or eventual out-of-memory compilation. The bug was that this code did not guard against transforming opaque constants. More details are in the post-commit mailing list thread for r347917. A reduced test for that is included in the x86 bool-math.ll file. (I wasn't able to reduce a PPC backend test for this, but it was almost the same pattern.) Original commit message for r347917: The motivating case for this is shown in: https://bugs.llvm.org/show_bug.cgi?id=32023 and the corresponding rot16.ll regression tests. Because x86 scalar shift amounts are i8 values, we can end up with trunc-binop-trunc sequences that don't get folded in IR. As the TODO comments suggest, there will be regressions if we extend this (for x86, we mostly seem to be missing LEA opportunities, but there are likely vector folds missing too). I think those should be considered existing bugs because this is the same transform that we do as an IR canonicalization in instcombine. We just need more tests to make those visible independent of this patch. llvm-svn: 348706
* [SelectionDAG] Remove ISD::ADDC/ADDE from some undef handling code in ↵Craig Topper2018-12-081-2/+0
| | | | | | | | getNode. NFCI These nodes should have two results. A real VT and a Glue. But this code would have returned Undef which would only be a single result. But we're in the single result version of getNode so these opcodes should never be seen by this function anyway. llvm-svn: 348670
* [GlobalISel] Add IR translation support for the @llvm.log10 intrinsicJessica Paquette2018-12-071-0/+5
| | | | | | | | This adds IR translation support for @llvm.log10 and updates relevant tests. https://reviews.llvm.org/D55392 llvm-svn: 348657
* Follow-up from r348441 to add the rest of the objc ARC intrinsics.Pete Cooper2018-12-071-0/+14
| | | | | | This adds the other intrinsics used by ARC and codegen's them to their respective runtime methods. llvm-svn: 348646
* [DAGCombiner] split trunc from extend in hoistLogicOpWithSameOpcodeHands; NFCSanjay Patel2018-12-071-33/+48
| | | | | | | This duplicates several shared checks, but we need to split this up to fix underlying bugs in smaller steps. llvm-svn: 348627
* [DAGCombiner] disable truncation of binops by defaultSanjay Patel2018-12-071-1/+7
| | | | | | | | | | As discussed in the post-commit thread of r347917, this transform is fighting with an existing transform causing an infinite loop or out-of-memory, so this is effectively reverting r347917 and its follow-up r348195 while we investigate the bug. llvm-svn: 348604
* [DAGCombiner] remove explicit calls to AddToWorkList; NFCISanjay Patel2018-12-071-6/+0
| | | | | | | | As noted in the post-commit thread for rL347917: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608936.html ...we don't need to repeat these calls because the combiner does it automatically. llvm-svn: 348597
* [SelectionDAG] Don't pass on DemandedElts when handling SCALAR_TO_VECTORSimon Pilgrim2018-12-071-1/+1
| | | | | | | | | | | | Fixes an assertion: llc: lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2200: llvm::KnownBits llvm::SelectionDAG::computeKnownBits(llvm::SDValue, const llvm::APInt&, unsigned int) const: Assertion `(!Op.getValueType().isVector() || NumElts == Op.getValueType().getVectorNumElements()) && "Unexpected vector size"' failed. Committed on behalf of: @pendingchaos (Rhys Perry) Differential Revision: https://reviews.llvm.org/D55223 llvm-svn: 348574
* [DAGCombiner] use root SDLoc for all nodes created by logic foldSanjay Patel2018-12-071-1/+1
| | | | | | | | | | | If this is not a valid way to assign an SDLoc, then we get this wrong all over SDAG. I don't know enough about the SDAG to explain this. IIUC, theoretically, debug info is not supposed to affect codegen. But here it has clearly affected 3 different targets, and the x86 change is an actual improvement. llvm-svn: 348552
* [DAGCombiner] don't bother saving a SDLoc for a node that's dead; NFCISanjay Patel2018-12-061-1/+1
| | | | | | | | | | | | | | We shouldn't care about the debug location for a node that we're creating, but attaching the root of the pattern should be the best effort. (If this is not true, then we are doing it wrong all over the SDAG). This is no-functional-change-intended, and there are no regression test diffs...and that's what I expected. But there's a similar line above this diff, where those assumptions apparently do not hold. llvm-svn: 348550
* [DAGCombiner] more clean up in hoistLogicOpWithSameOpcodeHands(); NFCSanjay Patel2018-12-061-41/+34
| | | | | | This code can still misbehave. llvm-svn: 348547
* [DAGCombiner] don't group bswap with casts in logic hoisting foldSanjay Patel2018-12-061-6/+15
| | | | | | | | | | | | | | | | This was probably organized as it was because bswap is a unary op. But that's where the similarity to the other opcodes ends. We should not limit this transform to scalars, and we should not try it if either input has other uses. This is another step towards trying to clean this whole function up to prevent it from causing infinite loops and memory explosions. Earlier commits in this series: rL348501 rL348508 rL348518 llvm-svn: 348534
* [DAGCombiner] reduce indent; NFCSanjay Patel2018-12-061-38/+31
| | | | | | | | Unlike some of the folds in hoistLogicOpWithSameOpcodeHands() above this shuffle transform, this has the expected hasOneUse() checks in place. llvm-svn: 348523
* [DagCombiner][X86] Simplify a ConcatVectors of a scalar_to_vector with undef.Andrea Di Biagio2018-12-061-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new DAGCombiner rule to simplify concat_vectors nodes: concat_vectors( bitcast (scalar_to_vector %A), UNDEF) --> bitcast (scalar_to_vector %A) This patch only partially addresses PR39257. In particular, it is enough to fix one of the two problematic cases mentioned in PR39257. However, it is not enough to fix the original test case posted by Craig; that particular case would probably require a more complicated approach (and knowledge about used bits). Before this patch, we used to generate the following code for function PR39257 (-mtriple=x86_64 , -mattr=+avx): vmovsd (%rdi), %xmm0 # xmm0 = mem[0],zero vxorps %xmm1, %xmm1, %xmm1 vblendps $3, %xmm0, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[2,3] vmovaps %ymm0, (%rsi) vzeroupper retq Now we generate this: vmovsd (%rdi), %xmm0 # xmm0 = mem[0],zero vmovaps %ymm0, (%rsi) vzeroupper retq As a side note: that VZEROUPPER is completely redundant... I guess the vzeroupper insertion pass doesn't realize that the definition of %xmm0 from vmovsd is already zeroing the upper half of %ymm0. Note that on %-mcpu=btver2, we don't get that vzeroupper because pass vzeroupper insertion %pass is disabled. Differential Revision: https://reviews.llvm.org/D55274 llvm-svn: 348522
* [DAGCombiner] don't hoist logic op if operands have other uses, part 2Sanjay Patel2018-12-061-5/+7
| | | | | | | | | The PPC test with 2 extra uses seems clearly better by avoiding this transform. With 1 extra use, we also prevent an extra register move (although that might be an RA problem). The general rule should be to only make a change here if it is always profitable. The x86 diffs are all neutral. llvm-svn: 348518
* Fix Wdocumentation warning. NFCI.Simon Pilgrim2018-12-061-2/+0
| | | | llvm-svn: 348517
* [DAGCombiner] don't hoist logic op if operands have other usesSanjay Patel2018-12-061-2/+6
| | | | | | | | | | | | | | | | | The AVX512 diffs are neutral, but the bswap test shows a clear overreach in hoistLogicOpWithSameOpcodeHands(). If we don't check for other uses, we can increase the instruction count. This could also fight with transforms trying to go in the opposite direction and possibly blow up/infinite loop. This might be enough to solve the bug noted here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html I did not add the hasOneUse() checks to all opcodes because I see a perf regression for at least one opcode. We may decide that's irrelevant in the face of potential compiler crashing, but I'll see if I can salvage that first. llvm-svn: 348508
* [DAGCombiner] refactor function that hoists bitwise logic; NFCISanjay Patel2018-12-061-56/+65
| | | | | | | | | Added FIXME and TODO comments for lack of safety checks. This function is a suspect in out-of-memory errors as discussed in the follow-up thread to r347917: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html llvm-svn: 348501
* DAGCombiner::visitINSERT_VECTOR_ELT - pull out repeated ↵Simon Pilgrim2018-12-061-3/+4
| | | | | | VT.getVectorNumElements(). NFCI. llvm-svn: 348494
* Test commit: Removed trailing space in .txt file.Markus Lavin2018-12-061-2/+2
| | | | llvm-svn: 348483
* Add objc.* ARC intrinsics and codegen them to their runtime methods.Pete Cooper2018-12-061-0/+36
| | | | | | | | Reviewers: erik.pilkington, ahatanak Differential Revision: https://reviews.llvm.org/D55233 llvm-svn: 348441
* [MachineOutliner][NFC] Move yet another std::vector out of a loopJessica Paquette2018-12-061-3/+4
| | | | | | | | Once again, following the wisdom of the LLVM Programmer's Manual. I think that's enough refactoring for today. :) llvm-svn: 348439
* [MachineOutliner][NFC] Move std::vector out of loopJessica Paquette2018-12-061-1/+2
| | | | | | See http://llvm.org/docs/ProgrammersManual.html#vector llvm-svn: 348433
* [MachineOutliner][NFC] Remove IntegerInstructionMap from InstructionMapperJessica Paquette2018-12-061-9/+2
| | | | | | | | | | Refactoring. This map was only used when we used a string of integers to output the outlined sequence. Since it's no longer used for anything, there's no reason to keep it around. llvm-svn: 348432
* [GlobalISel] Introduce G_BUILD_VECTOR, G_BUILD_VECTOR_TRUNC and ↵Amara Emerson2018-12-052-0/+115
| | | | | | | | | | | | | | | | | | | | | | | G_CONCAT_VECTOR opcodes. These opcodes are intended to subsume some of the capability of G_MERGE_VALUES, as it was too powerful and thus complex to add deal with throughout the GISel pipeline. G_BUILD_VECTOR creates a vector value from a sequence of uniformly typed scalar values. G_BUILD_VECTOR_TRUNC is a special opcode for handling scalar operands which are larger than the destination vector element type, and therefore does an implicit truncate. G_CONCAT_VECTOR creates a vector by concatenating smaller, uniformly typed, vectors together. These will be used in a subsequent commit. This commit just adds the initial infrastructure. Differential Revision: https://reviews.llvm.org/D53594 llvm-svn: 348430
* [MachineOutliner][NFC] Remove buildCandidateList and replace with findCandidatesJessica Paquette2018-12-051-45/+9
| | | | | | | | | | | | | | More refactoring. Since the pruning logic has changed, and the candidate list is gone, everything can be sunk into findCandidates. We no longer need to keep track of the length of the longest substring, so we can drop all of that logic as well. After this, we just find all of the candidates and move to outlining. llvm-svn: 348428
* [MachineOutliner][NFC] Candidates don't need to be shared_ptrs anymoreJessica Paquette2018-12-051-11/+10
| | | | | | | | | | | More refactoring. After the changes to the pruning logic, and removing CandidateList, there's no reason for Candiates to be shared_ptrs (or pointers at all). std::shared_ptr<Candidate> -> Candidate. llvm-svn: 348427
* [MachineOutliner][NFC] Remove CandidateList, since it's now unused.Jessica Paquette2018-12-051-29/+11
| | | | | | | After removing the pruning logic, there's no reason to populate a list of Candidates. Remove CandidateList and update comments. llvm-svn: 348422
* Fix buildbot capture warningJessica Paquette2018-12-051-9/+6
| | | | | | | | | | | | | A bot didn't like my lambda. This ought to fix it. Example: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/30139/steps/build%20lld/logs/stdio error C3493: 'AlreadyRemoved' cannot be implicitly captured because no default capture mode has been specified llvm-svn: 348421
* [MachineOutliner][NFC] Simplify and unify pruning/outlining logicJessica Paquette2018-12-051-157/+15
| | | | | | | | | | | | | | Since we're now performing outlining per OutlinedFunction rather than per Candidate, we can simply outline each candidate as it shows up. Instead of having a pruning phase, instead, we'll outline entire functions. Then we'll update the UnsignedVec we mapped to reflect the deletion. If any candidate is in a space that's marked dirty, then we'll drop it. This lets us remove the pruning logic entirely, and greatly simplifies the code. llvm-svn: 348420
* [MachineOutliner] Outline functions by order of benefitJessica Paquette2018-12-051-63/+68
| | | | | | | | | | | | | | | | | | Mostly NFC, only change is the order of outlined function names. Loop over the outlined functions instead of walking the candidate list. This is a bit easier to understand. It's far more natural to create a function, then replace all of its occurrences with calls than the other way around. The functions outlined after this do not change, but their names will be decided by their benefit. E.g, OUTLINED_FUNCTION_0 will now always be the most beneficial function, rather than the first one seen. This makes it easier to enforce an ordering on the outlined functions. So, this also adds a test to make sure that the ordering works as expected. llvm-svn: 348414
* [GISel]: Provide standard interface to observe changes in GISel passesAditya Nandakumar2018-12-056-65/+102
| | | | | | | | | | | | | https://reviews.llvm.org/D54980 This provides a standard API across GISel passes to observe and notify passes about changes (insertions/deletions/mutations) to MachineInstrs. This patch also removes the recordInsertion method in MachineIRBuilder and instead provides method to setObserver. Reviewed by: vkeles. llvm-svn: 348406
* [MachineOutliner][NFC] Don't create outlined sequence from integer mappingJessica Paquette2018-12-051-13/+6
| | | | | | | | | | | Some gardening/refactoring. It's cleaner to copy the instructions into the MachineFunction using the first candidate instead of going to the mapper. Also, by doing this we can remove the Seq member from OutlinedFunction entirely. llvm-svn: 348390
* [DAGCombiner] don't try to extract a fraction of a vector binop and crash ↵Sanjay Patel2018-12-051-10/+14
| | | | | | | | | | | | | (PR39893) Because we're potentially peeking through a bitcast in this transform, we need to use overall bitwidths rather than number of elements to determine when it's safe to proceed. Should fix: https://bugs.llvm.org/show_bug.cgi?id=39893 llvm-svn: 348383
* [TargetLowering] Remove ISD::ANY_EXTEND/ANY_EXTEND_VECTOR_INREG opcodes from ↵Simon Pilgrim2018-12-051-2/+0
| | | | | | | | SimplifyDemandedVectorElts These have no test coverage and the KnownZero flags can't be guaranteed unlike SIGN/ZERO_EXTEND cases. llvm-svn: 348361
* [SelectionDAG] Initial support for FSHL/FSHR funnel shift opcodes (PR39467)Simon Pilgrim2018-12-057-38/+151
| | | | | | | | | | This is an initial patch to add a minimum level of support for funnel shifts to the SelectionDAG and to begin wiring it up to the X86 SHLD/SHRD instructions. Some partial legalization code has been added to handle the case for 'SlowSHLD' where we want to expand instead and I've added a few DAG combines so we don't get regressions from the existing DAG builder expansion code. Differential Revision: https://reviews.llvm.org/D54698 llvm-svn: 348353
* Remove superfluous comments. NFCI.Simon Pilgrim2018-12-051-44/+38
| | | | | | As requested in D54698. llvm-svn: 348350
* [TargetLowering] SimplifyDemandedVectorElts - don't alter DemandedElts maskSimon Pilgrim2018-12-051-2/+3
| | | | | | | | Fix potential issue with the ISD::INSERT_VECTOR_ELT case tweaking the DemandedElts mask instead of using a local copy - so later uses of the mask use the tweaked version..... Noticed while investigating adding zero/undef folding to SimplifyDemandedVectorElts and the altered DemandedElts mask was causing mismatches. llvm-svn: 348348
* [MachineLICM][X86][AMDGPU] Fix subtle bug in the updating of PhysRegClobbers ↵Craig Topper2018-12-051-1/+5
| | | | | | | | | | | | | | in post-RA LICM It looks like MCRegAliasIterator can visit the same physical register twice. When this happens in this code in LICM we end up setting the PhysRegDef and then later in the same loop visit the register again. Now we see that PhysRegDef is set from the earlier iteration so now set PhysRegClobber. This patch splits the loop so we have one that uses the previous value of PhysRegDef to update PhysRegClobber and second loop that updates PhysRegDef. The X86 atomic test is an improvement. I had to add sideeffect to the two shrink wrapping tests to prevent hoisting from occurring. I'm not sure about the AMDGPU tests. It looks like the branch instruction changed at end the of the loops. And in the branch-relaxation test I think there is now "and vcc, exec, -1" instruction that wasn't there before. Differential Revision: https://reviews.llvm.org/D55102 llvm-svn: 348330
* [SelectionDAG] Split very large token factors for loads into 64k chunks.Amara Emerson2018-12-052-3/+17
| | | | | | | | | | | | | | | There's a 64k limit on the number of SDNode operands, and some very large functions with 64k or more loads can cause crashes due to this limit being hit when a TokenFactor with this many operands is created. To fix this, create sub-tokenfactors if we've exceeded the limit. No test case as it requires a very large function. rdar://45196621 Differential Revision: https://reviews.llvm.org/D55073 llvm-svn: 348324
* [SelectionDAG] Redefine isGAPlusOffset in terms of unwrapAddress. NFCI.Nirav Dave2018-12-041-1/+4
| | | | llvm-svn: 348288
* MIR: Add method to stop after specific runs of passesMatt Arsenault2018-12-041-8/+38
| | | | | | | | | | Currently if you use -{start,stop}-{before,after}, it picks the first instance with the matching pass name. If you run the same pass multiple times, there's no way to distinguish them. Allow specifying a run index wih ,N to specify which you mean. llvm-svn: 348285
* [TargetLowering] expandFP_TO_UINT - avoid FPE due to out of range conversion ↵Simon Pilgrim2018-12-041-11/+30
| | | | | | | | | | | | | | (PR17686) PR17686 demonstrates that for some targets FP exceptions can fire in cases where the FP_TO_UINT is expanded using a FP_TO_SINT instruction. The existing code converts both the inrange and outofrange cases using FP_TO_SINT and then selects the result, this patch changes this for 'strict' cases to pre-select the FP_TO_SINT input and the offset adjustment. The X87 cases don't need the strict flag but generates much nicer code with it.... Differential Revision: https://reviews.llvm.org/D53794 llvm-svn: 348251
* [TargetLowering] Add SimplifyDemandedVectorElts support to EXTEND opcodesSimon Pilgrim2018-12-042-0/+23
| | | | | | | | Add support for ISD::*_EXTEND and ISD::*_EXTEND_VECTOR_INREG opcodes. The extra broadcast in trunc-subvector.ll will be fixed in an upcoming patch. llvm-svn: 348246
* [DAGCombiner] narrow truncated vector binops when legalSanjay Patel2018-12-031-7/+11
| | | | | | | | | | | | | | | | This is the smallest vector enhancement I could find to D54640. Here, we're allowing narrowing to only legal vector ops because we'll see regressions without that. All of the test diffs are wins from what I can tell. With AVX/AVX512, we can shrink ymm/zmm ops to xmm. x86 vector multiplies are the problem case that we're avoiding due to the patchwork ISA, and it's not clear to me if we can dance around those regressions using TLI hooks or if we need preliminary patches to plug those holes. Differential Revision: https://reviews.llvm.org/D55126 llvm-svn: 348195
OpenPOWER on IntegriCloud