summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Include what you use in HexagonELFObjectWriter.cppDmitri Gribenko2019-06-031-1/+1
| | | | | | | | | | HexagonELFObjectWriter.cpp was not using any APIs from Hexagon.h, and was only including it for transitive dependencies. Doing so is problematic from include-what-you-use perspective, but it is also a layering issue (it creates a dependency cycle between the primary Hexagon target library and the MCTargetDesc library). llvm-svn: 362376
* [LiveDebugValues] Close range for previous variable's location when adding ↵Nikola Prica2019-06-031-1/+11
| | | | | | | | | | | | | | | | | | | | | | newly deduced location When LiveDebugValues deduces new variable's location from spill, restore or register copy instruction it should close old variable's location. Otherwise we can have multiple block output locations for same variable. That could lead to inserting two DBG_VALUEs for same variable to the beginning of the successor block which results to ignoring of first DBG_VALUE. Reviewers: aprantl, jmorse, wolfgangp, dstenb Reviewed By: aprantl Subscribers: probinson, asowda, ivanbaev, petarj, djtodoro Tags: #debug-info Differential Revision: https://reviews.llvm.org/D62196 llvm-svn: 362373
* Include what you use in HexagonAsmBackend.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonAsmBackend.cpp was not using any APIs from Hexagon.h. Doing so is problematic from include-what-you-use perspective, but it is also a layering issue (it creates a dependency cycle between the primary Hexagon target library and the MCTargetDesc library). llvm-svn: 362372
* Include what you use in HexagonAsmParser.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonAsmParser.cpp was not using any APIs from Hexagon.h. Doing so is problematic from include-what-you-use perspective, but it is also a layering issue (it creates a dependency cycle between the primary Hexagon target library and the AsmParser library). llvm-svn: 362370
* Include what you use in HexagonShuffler.hDmitri Gribenko2019-06-031-1/+1
| | | | | | | | | | HexagonShuffler.h was not using any APIs from Hexagon.h, and was only including it for transitive dependencies. Doing so is problematic from include-what-you-use perspective, but it is also a layering issue (it creates a dependency cycle between the primary Hexagon target library and the MCTargetDesc library). llvm-svn: 362369
* Include what you use in BPFMCTargetDesc.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | BPFMCTargetDesc.cpp was not using any APIs from BPF.h. Doing so is problematic from include-what-you-use perspective, but it is also a layering issue (it creates a dependency cycle between the primary BPF target library and the MCTargetDesc library). llvm-svn: 362368
* [ARM][FIX] Ran out of registers due tail recursionDiogo N. Sampaio2019-06-032-49/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - pr42062 When compiling for MinSize, ARMTargetLowering::LowerCall decides to indirect multiple calls to a same function. However, it disconsiders the limitation that thumb1 indirect calls require the callee to be in a register from r0 to r3 (llvm limiation). If all those registers are used by arguments, the compiler dies with "error: run out of registers during register allocation". This patch tells the function IsEligibleForTailCallOptimization if we intend to perform indirect calls, as to avoid tail call optimization. Reviewers: dmgreen, efriedma Reviewed By: efriedma Subscribers: javed.absar, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62683 llvm-svn: 362366
* [AArch64] Check for simple type in FPToUIntSam Parker2019-06-031-0/+3
| | | | | | | | | | | DAGCombiner was hitting a SimpleType assertion when trying to combine a v3f32 before type legalization. bugzilla: https://bugs.llvm.org/show_bug.cgi?id=41916 Differential Revision: https://reviews.llvm.org/D62734 llvm-svn: 362365
* [AVR] Fix incorrect source regclass of LDWRdPtrJim Lin2019-06-032-6/+6
| | | | | | | | | | | | | | | | | | Summary: LDWRdPtr would be expanded to ld+ldd. ldd only accepts the pointer register is Y or Z. So the register class of pointer of LDWRdPtr should be PTRDISPREGS instead of PTRREGS. Reviewers: dylanmckay Reviewed By: dylanmckay Subscribers: dylanmckay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62300 llvm-svn: 362351
* Recommit r360171: [DAGCombiner] Avoid creating large tokenfactors in ↵Florian Hahn2019-06-031-3/+21
| | | | | | | | | | | | | | | | visitTokenFactor. If we hit the limit, we do expand the outstanding tokenfactors. Otherwise, we might drop nodes with users in the unexpanded tokenfactors. This fixes the crashes reported by Jordan Rupprecht. Reviewers: niravd, spatel, craig.topper, rupprecht Reviewed By: niravd Differential Revision: https://reviews.llvm.org/D62633 llvm-svn: 362350
* llvm-undname; Add more test coverage for demangleFunctionClass()Nico Weber2019-06-021-2/+2
| | | | | | | | Also add two FC_Far that seem to be missing, by symmetry from the public and protected cases. (But FC_Far isn't really a thing anymore, so this doesn't really have an observable effect.) llvm-svn: 362344
* [DAGCombiner][X86] Fold away masked store and scatter with all zeroes mask.Craig Topper2019-06-021-11/+18
| | | | | | Similar to what was done for masked load and gather. llvm-svn: 362342
* [X86] Add test cases for masked store and masked scatter with an all zeroes ↵Craig Topper2019-06-021-1/+1
| | | | | | | | | mask. Fix bug in ScalarizeMaskedMemIntrin Need to cast only to Constant instead of ConstantVector to allow ConstantAggregateZero. llvm-svn: 362341
* [CostModel][X86] Improve masked load/store AVX1/AVX2 costsSimon Pilgrim2019-06-021-2/+2
| | | | | | | | | | | | | | | | | | | | A mixture of internal tests and review of the scheduler models indicates we're overestimating the cost of a masked load, which we're estimating at 4x regular memory ops - more realistic values indicates that its closer to 2x. Masked stores costs are a lot more diverse but 8x is roughly in the middle of the range. e.g. SandyBridge defm : X86WriteRes<WriteFMaskedLoad, [SBPort23,SBPort05], 8, [1,2], 3>; defm : X86WriteRes<WriteFMaskedLoadY, [SBPort23,SBPort05], 9, [1,2], 3>; defm : X86WriteRes<WriteFMaskedStore, [SBPort4,SBPort01,SBPort23], 5, [1,1,1], 3>; defm : X86WriteRes<WriteFMaskedStoreY, [SBPort4,SBPort01,SBPort23], 5, [1,1,1], 3>; e.g. Btver2 defm : X86WriteRes<WriteFMaskedLoad, [JLAGU, JFPU01, JFPX], 6, [1, 2, 2], 1>; defm : X86WriteRes<WriteFMaskedLoadY, [JLAGU, JFPU01, JFPX], 6, [2, 4, 4], 2>; defm : X86WriteRes<WriteFMaskedStore, [JSAGU, JFPU01, JFPX], 6, [1, 1, 4], 1>; defm : X86WriteRes<WriteFMaskedStoreY, [JSAGU, JFPU01, JFPX], 6, [2, 2, 4], 2>; Differential Revision: https://reviews.llvm.org/D61257 llvm-svn: 362338
* [DAGCombiner] Replace masked loads with a zero mask with the passthru valueCraig Topper2019-06-021-3/+7
| | | | | | Similar to what was recently done for gathers in r362015. llvm-svn: 362337
* [TTI][X86] Cleanup getMaskedMemoryOpCost. NFCI.Simon Pilgrim2019-06-021-8/+11
| | | | | | Prep work before resurrecting D61257. llvm-svn: 362335
* Remove code path that's dead after r358835Nico Weber2019-06-021-4/+2
| | | | llvm-svn: 362333
* [X86] isHorizontalBinOp - add extract_subvector(shuffle(x)) handling (PR39921)Simon Pilgrim2019-06-021-5/+22
| | | | | | Let's us match horizontal op patterns on fast-variable-shuffle targets (Haswell etc.) llvm-svn: 362327
* [DAGCombine] Fold insert_subvector(bitcast(x),bitcast(y),c1) -> ↵Simon Pilgrim2019-06-022-36/+37
| | | | | | | | | | bitcast(insert_subvector(x,y),c2) Move this combine from x86 into generic DAGCombine, which currently only manages cases where the bitcast is between types of the same scalarsize. Differential Revision: https://reviews.llvm.org/D59188 llvm-svn: 362324
* [DAG] isBitwiseNot / isConstOrConstSplat - add support for build vector ↵Simon Pilgrim2019-06-021-13/+28
| | | | | | | | | | | | undefs + truncation (PR41020) Add (opt-in) support for implicit truncation to isConstOrConstSplat, which allows us to match truncated 'all ones' cases in isBitwiseNot. PR41020 compares against using ISD::isBuildVectorAllOnes() instead, but that predicate silently accepts any UNDEF elements in the build vector which might not be what we want in isBitwiseNot - so I've added an opt-in 'AllowUndefs' flag that is set to false by default but will allow us to enable it on individual cases where its safe. Differential Revision: https://reviews.llvm.org/D62783 llvm-svn: 362323
* [TargetLowering] SimplifyDemandedBits - don't use OriginalDemanded variables ↵Simon Pilgrim2019-06-021-5/+5
| | | | | | | | in analysis. These might have been replaced in multiple use cases. llvm-svn: 362322
* [TargetLowering] SimplifyDemandedVectorElts - use same arg names as ↵Simon Pilgrim2019-06-021-4/+4
| | | | | | | | SimplifyDemandedBits. NFCI. Helps with debugging as we recurse between them. llvm-svn: 362321
* [DAGCombiner] Replace two unchecked dyn_casts with casts.Craig Topper2019-06-021-2/+2
| | | | | | | | | | The results of the dyn_casts were immediately dereferenced on the next line so they had better not be null. I don't think there's any way for these dyn_casts to fail, so use a cast of adding null check. llvm-svn: 362315
* [X86] Fix several places that weren't passing what they though they were to ↵Craig Topper2019-06-023-6/+14
| | | | | | | | | | MachineInstr::print Over a year ago, MachineInstr gained a fourth boolean parameter that occurs before the TII pointer. When this happened, several places started accidentally passing TII into this boolean parameter instead of the TII parameter. llvm-svn: 362312
* [X86] Add the SSE versions of PMULLW and PMULLD to isAssociativeAndCommutative.Craig Topper2019-06-021-0/+2
| | | | llvm-svn: 362309
* [SimplifyIndVar] Refactor overflow check elimination code; NFCNikita Popov2019-06-011-97/+43
| | | | | | | | | | | Extract a willNotOverflow() helper function that is shared between eliminateOverflowIntrinsic() and strengthenOverflowingOperation(). Use WithOverflowInst for the former. We'll be able to reuse the same code for saturating intrinsics as well. llvm-svn: 362305
* [InlineCost] Don't add the soft float function call cost for the fneg idiom, ↵Craig Topper2019-06-011-2/+5
| | | | | | | | | | | | | | | | | | fsub -0.0, %x Summary: Fneg can be implemented with an xor rather than a function call so we don't need to add the function call overhead. This was pointed out in D62699 Reviewers: efriedma, cameron.mcinally Reviewed By: efriedma Subscribers: javed.absar, eraman, hiraditya, haicheng, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62747 llvm-svn: 362304
* [MCA][Scheduler] Change how memory instructions are dispatched to the ↵Andrea Di Biagio2019-06-011-28/+25
| | | | | | pending set. NFCI llvm-svn: 362302
* [mips] Extend range of register indexes accepted by cfcmsa/ctcmsaSimon Atanasyan2019-06-012-13/+9
| | | | | | | | | | | | | | | | | The `cfcmsa` and `ctcmsa` instructions accept index of MSA control register. The MIPS64 SIMD Architecture define eight MSA control registers. But register index for `cfcmsa` and `ctcmsa` instructions might be any number in 0..31 range. If the index is greater then 7, `cfcmsa` writes zero to the destination registers and `ctcmsa` does nothing [1]. [1] MIPS Architecture for Programmers Volume IV-j: The MIPS64 SIMD Architecture Module https://www.mips.com/?do-download=the-mips64-simd-architecture-module Differential Revision: https://reviews.llvm.org/D62597 llvm-svn: 362299
* [AVR] Disable register coalescing to the PTRDISPREGS classDylan McKay2019-06-012-0/+22
| | | | | | | | | | | | | If we would allow register coalescing on PTRDISPREGS class then register allocator can lock Z register to some virtual register. Larger instructions requiring a memory acces then fail during the register allocation phase since there is no available register to hold a pointer if Y register was already taken for a stack frame. This patch prevents it by keeping Z register spillable. It does it by not allowing coalescer to lock it. Original discussion on https://github.com/avr-rust/rust/issues/128. llvm-svn: 362298
* [IndVarSimplify] Fixup nowrap flags during LFTR (PR31181)Nikita Popov2019-06-011-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix for LFTR poison handling issues in general. When LFTR moves a condition from pre-inc to post-inc, it may now depend on value that is poison due to nowrap flags. To avoid this, we clear any nowrap flag that SCEV cannot prove for the post-inc addrec. Additionally, LFTR may switch to a different IV that is dynamically dead and as such may be arbitrarily poison. This patch will correct nowrap flags in some but not all cases where this happens. This is related to the adoption of IR nowrap flags for the pre-inc addrec. (See some of the switch_to_different_iv tests, where flags are not dropped or insufficiently dropped.) Finally, there are likely similar issues with the handling of GEP inbounds, but we don't have a test case for this yet. Differential Revision: https://reviews.llvm.org/D60935 llvm-svn: 362292
* Extend the DWARFExpression address handling to support 16-bit addressesDylan McKay2019-06-011-4/+8
| | | | | | | | | | | | | | This allows the DWARFExpression class to handle addresses without crashing on targets with 16-bit pointers like AVR. This is required in order to generate assembly from clang via the '-S' flag. This fixes an error with the following message: clang: llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h:132: llvm::DWARFExpression::DWARFExpression(llvm::DataExtractor, uint16_t, uint8_t): Assertion `AddressSize == 8 || AddressSize == 4' failed. llvm-svn: 362290
* [X86] Add AVX512BF16 and AVX512VP2INTERSECT instructions to the loading ↵Craig Topper2019-06-011-0/+33
| | | | | | folding tables. llvm-svn: 362288
* [X86] Make the X86FoldTablesEmitter functional again. Fix the spacing in the ↵Craig Topper2019-06-011-4/+2
| | | | | | | | | output to make it easier to diff. Fix a few other formatting issues in the manual table. And remove some old FIXMEs. llvm-svn: 362287
* [RuntimeDyld] fix too-small-bitmask errorNick Desaulniers2019-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No. 33". It seems that this statement is doing the standard bitwise trick for adjusting a value to have a specific alignment. The issue is that getStubAlignment() returns an unsigned, while DataSize is declared a uint64_t. The right hand side of the expression is not extended to 64b before bitwise negation, resulting in the top half of the mask being 0s, which is not correct for realignment. Reviewers: lhames, MaskRay Reviewed By: MaskRay Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D62227 llvm-svn: 362286
* Inline variable into assert to fix unused variable warning.Richard Trieu2019-06-011-3/+3
| | | | llvm-svn: 362285
* [LoopPred] Eliminate a redundant/confusing cover function [NFC]Philip Reames2019-06-011-19/+20
| | | | llvm-svn: 362284
* [LoopPred] Handle a subset of NE comparison based latchesPhilip Reames2019-06-011-21/+33
| | | | | | | | | | | | | | | | | | | | | At the moment, LoopPredication completely bails out if it sees a latch of the form: %cmp = icmp ne %iv, %N br i1 %cmp, label %loop, label %exit OR %cmp = icmp ne %iv.next, %NPlus1 br i1 %cmp, label %loop, label %exit This is unfortunate since this is exactly the form that LFTR likes to produce. So, go ahead and recognize simple cases where we can. For pre-increment loops, we leverage the fact that LFTR likes canonical counters (i.e. those starting at zero) and a (presumed) range fact on RHS to discharge the check trivially. For post-increment forms, the key insight is in remembering that LFTR had to insert a (N+1) for the RHS. CVP can hopefully prove that add nsw/nuw (if there's appropriate range on N to start with). This leaves us both with the post-inc IV and the RHS involving an nsw/nuw add, and SCEV can discharge that with no problem. This does still need to be extended to handle non-one steps, or other harder patterns of variable (but range restricted) starting values. That'll come later. Differential Revision: https://reviews.llvm.org/D62748 llvm-svn: 362282
* [CodeGen] Fix hashing for MO_ExternalSymbol MachineOperands.Eli Friedman2019-06-011-1/+1
| | | | | | | | | | | | | | | | | We were hashing the string pointer, not the string, so two instructions could be identical (isIdenticalTo), but have different hash codes. This showed up as a very rare, non-deterministic assertion failure rehashing a DenseMap constructed by MachineOutliner. So there's no "real" testcase, just a unittest which checks that the hash function behaves correctly. I'm a little scared fixing this is going to cause a regression in outlining or MachineCSE, but hopefully we won't run into any issues. Differential Revision: https://reviews.llvm.org/D61975 llvm-svn: 362281
* [COFF, ARM64] Add CodeView register mappingTom Tan2019-05-315-21/+229
| | | | | | | | | | | | | | | | CodeView has its own register map which is defined in cvconst.h. Missing this mapping before saving register to CodeView causes debugger to show incorrect value for all register based variables, like variables in register and local variables addressed by register (stack pointer + offset). This change added mapping between LLVM register and CodeView register so the correct register number will be stored to CodeView/PDB, it aso fixed the mapping from CodeView register number to register name based on current CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed. Differential Revision: https://reviews.llvm.org/D62608 llvm-svn: 362280
* [PowerPC] check for INLINEASM_BR along w/ INLINEASMNick Desaulniers2019-05-312-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: It looks like since INLINEASM_BR was created off of INLINEASM (r353563), a few checks for INLINEASM needed to be updated to check for either case. pr/41999 Reviewers: hfinkel Reviewed By: hfinkel Subscribers: nemanjai, hiraditya, kbarton, jsji, llvm-commits, craig.topper, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D62403 llvm-svn: 362278
* [codeview] Revert inline line table change of r362264Reid Kleckner2019-05-311-0/+1
| | | | | | | | | | | | Testing with debuggers shows that our previous behavior was correct. The reason I thought MSVC did things differently is that MSVC prefers to use the 0xB combined code offset and code length update opcode when inline sites are discontiguous. Keep the test changes, and update the llvm-pdbutil inline line table dumper to account for this new interpretation of the opcodes. llvm-svn: 362277
* AMDGPU: Fix not adding ImplicitBufferPtr as a live-inMatt Arsenault2019-05-311-1/+4
| | | | | | Fixes missing test from r293000. llvm-svn: 362275
* [SimplifyLibCalls] Fold more fortified functions into non-fortified variantsErik Pilkington2019-05-313-15/+256
| | | | | | | | | | | | When the object size argument is -1, no checking can be done, so calling the _chk variant is unnecessary. We already did this for a bunch of these functions. rdar://50797197 Differential revision: https://reviews.llvm.org/D62358 llvm-svn: 362272
* NFC: Pull out a function to reduce some duplicationErik Pilkington2019-05-312-119/+70
| | | | | | Part of https://reviews.llvm.org/D62358 llvm-svn: 362271
* [SelectionDAG] Make the code in mutateStrictFPToFP less aware of how many ↵Craig Topper2019-05-311-55/+34
| | | | | | | | | | | | | operands each node has. NFCI Just copy all of the operands except the chain and call MorphNode on that. This removes the IsUnary and IsTernary flags. Also always get the result type from the result type of the original nodes. Previously we got it from the operand except for two nodes where that didn't work. llvm-svn: 362269
* [RegisterCoalescer] fix potential use of undef value. NFCNick Desaulniers2019-05-311-7/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes a warning produced from scan-build (llvm.org/reports/scan-build/), further warnings found by annotation isMoveInstr [[nodiscard]]. isMoveInstr potentially does not assign to its parameters, so if they were uninitialized, they will potentially stay uninitialized. It seems most call sites pass references to uninitialized values, then use them without checking the return value. Reviewers: wmi Reviewed By: wmi Subscribers: MatzeB, qcolombet, hiraditya, tpr, llvm-commits, srhines Tags: #llvm Differential Revision: https://reviews.llvm.org/D62109 llvm-svn: 362265
* [codeview] Fix inline line table accuracy for discontiguous segmentsReid Kleckner2019-05-311-1/+0
| | | | | | | | | | | | | | | | After improving the inline line table dumper in llvm-pdbutil and looking at MSVC's inline line tables, it is clear that setting the length of the inlined code region does not update the code offset. This means that the delta to the beginning of a new discontiguous inlined code region should be calculated relative to the last code offset, excluding the length. Implementing this is a one line fix for MC: simply don't update LastLabel. While I'm updating these test cases, switch them to use llvm-objdump -d and llvm-pdbutil. This allows us to show offsets of each instruction and correlate the line table offsets to the actual code. llvm-svn: 362264
* Reapply [CVP] Simplify non-overflowing saturating add/subNikita Popov2019-05-311-1/+24
| | | | | | | | | | | | | If we can determine that a saturating add/sub will not overflow based on range analysis, convert it into a simple binary operation. This is a sibling transform to the existing with.overflow handling. Reapplying this with an additional check that the saturating intrinsic has integer type, as LVI currently does not support vector types. Differential Revision: https://reviews.llvm.org/D62703 llvm-svn: 362263
* [CVP] Fix assertion failure on vector with.overflowNikita Popov2019-05-311-1/+1
| | | | | | | | Noticed on D62703. LVI only handles plain integers, not vectors of integers. This was previously not an issue, because vector support for with.overflow is only a relatively recent addition. llvm-svn: 362261
OpenPOWER on IntegriCloud