summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [ConstantRange] Add sdiv() supportNikita Popov2019-06-031-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | The implementation is conceptually simple: We separate the LHS and RHS into positive and negative components and then also compute the positive and negative components of the result, taking into account that e.g. only pos/pos and neg/neg will give a positive result. However, there's one significant complication: SignedMin / -1 is UB for sdiv, and we can't just ignore it, because the APInt result of SignedMin would break the sign segregation. Instead we drop SignedMin or -1 from the corresponding ranges, taking into account some edge cases with wrapped ranges. Because of the sign segregation, the implementation ends up being nearly fully precise even for wrapped ranges (the remaining imprecision is due to ranges that are both signed and unsigned wrapping and are divided by a trivial divisor like 1). This means that the testing cannot just check the signed envelope as we usually do. Instead we collect all possible results in a bitvector and construct a better sign wrapped range (than the full envelope). Differential Revision: https://reviews.llvm.org/D61238 llvm-svn: 362430
* Fix a crash when the default of a switch is removedAndrew Kaylor2019-06-031-0/+5
| | | | | | | | This patch fixes a problem that occurs in LowerSwitch when a switch statement has a PHI node as its condition, and the PHI node only has two incoming blocks, and one of those incoming blocks is through an unreachable default in the switch statement. When this condition occurs, LowerSwitch holds a pointer to the condition value, but removes the switch block as a predecessor of the PHI block, causing the PHI node to be replaced. LowerSwitch then tries to use its stale pointer to the original condition value, causing a crash. Differential Revision: https://reviews.llvm.org/D62560 llvm-svn: 362427
* Include what you use in Lanai.hDmitri Gribenko2019-06-033-6/+3
| | | | | | | Other files were not relying on these transitive includes, so I'm submitting this change separately. llvm-svn: 362423
* Include what you use in LanaiAsmPrinter.cppDmitri Gribenko2019-06-031-1/+2
| | | | llvm-svn: 362422
* Include what you use in LanaiMemAluCombiner.cppDmitri Gribenko2019-06-031-1/+1
| | | | llvm-svn: 362421
* Include what you use in LanaiISelDAGToDAG.cppDmitri Gribenko2019-06-031-1/+1
| | | | llvm-svn: 362420
* Include what you use in LanaiFrameLowering.{cpp,h}Dmitri Gribenko2019-06-032-2/+0
| | | | llvm-svn: 362419
* Include what you use in LanaiRegisterInfo.cppDmitri Gribenko2019-06-031-2/+4
| | | | llvm-svn: 362416
* [LoopPred] Convert a second member function to a static helper [NFC]Philip Reames2019-06-031-14/+15
| | | | | | (And remember to actually mark the first one static.) llvm-svn: 362415
* Revert "[llvm-ar] Fix relative thin archive path handling"Dmitri Gribenko2019-06-032-42/+20
| | | | | | | | | | This reverts commit r362407. It broke compilation of llvm/lib/Object/ArchiveWriter.cpp: error: type 'llvm::sys::path::const_iterator' does not provide a call operator llvm-svn: 362413
* [PowerPC] Set PROT_READ flag for MF_EXEC to prevent segfaults on PPC machinesNemanja Ivanovic2019-06-031-3/+2
| | | | | | | | | | | | | | | | | The big endian PPC buildbots are all failing now due to calls to cache invalidation in unit tests on data that has only the PROT_EXEC flag set. This has been an issue all along on FreeBSD but it can affect Linux machines depending on configuration. This patch mitigates the issue the same way it is mitigated on FreeBSD. Since this is needed to bring the buildbots back to green, I plan to commit this and allow for post-commit review, but I thought I would also post it here for ease of access/readability. Differential revision: https://reviews.llvm.org/D62741 llvm-svn: 362412
* [LoopPred] Convert member function to free helper function [NFC]Philip Reames2019-06-031-43/+47
| | | | llvm-svn: 362411
* Include what you use in LanaiInstrInfo.cppDmitri Gribenko2019-06-031-3/+3
| | | | llvm-svn: 362408
* [llvm-ar] Fix relative thin archive path handlingOwen Reynolds2019-06-032-20/+42
| | | | | | | | This fixes some thin archive relative path issues, paths are shortened where possible and paths are output correctly when using the display table command. Differential Revision: https://reviews.llvm.org/D59491 llvm-svn: 362407
* Include what you use in PPCInstrInfo.hDmitri Gribenko2019-06-031-1/+0
| | | | llvm-svn: 362405
* Include what you use in NVPTX.hDmitri Gribenko2019-06-031-7/+2
| | | | | | | Other files were not relying on these transitive includes, so I'm submitting this change separately. llvm-svn: 362403
* Include what you use in NVPTX.hDmitri Gribenko2019-06-037-2/+6
| | | | | | | I also fixed all other files that were including NVPTX.h and were relying on transitive includes. llvm-svn: 362402
* [AMDGPU][MC] Added support of SCC, VCCZ and EXECZ operandsDmitry Preobrazhensky2019-06-037-24/+69
| | | | | | | | | | See bug 39292: https://bugs.llvm.org/show_bug.cgi?id=39292 Reviewers: rampitec, arsenm Differential Revision: https://reviews.llvm.org/D62660 llvm-svn: 362400
* [SelectionDAG] Add [us]itofp(undef) --> 0 constant fold (PR39205)Simon Pilgrim2019-06-032-0/+14
| | | | | | | | We were missing this fold in the DAG, which I've copied directly from llvm::ConstantFoldCastInstruction Differential Revision: https://reviews.llvm.org/D62807 llvm-svn: 362397
* Include what you use in LanaiInstPrinter.cppDmitri Gribenko2019-06-031-1/+4
| | | | llvm-svn: 362395
* Include what you use in LanaiMCCodeEmitter.cppDmitri Gribenko2019-06-031-1/+1
| | | | | | | | | | LanaiMCCodeEmitter.cpp was not using any APIs from Lanai.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 Lanai target library and the MCTargetDesc library). llvm-svn: 362394
* Include what you use in LanaiDisassembler.cppDmitri Gribenko2019-06-031-2/+3
| | | | llvm-svn: 362392
* AMDGPU/GFX10: V_CMPX_xxx instructions still have an omod operandNicolai Haehnle2019-06-031-2/+1
| | | | | | | | | | | | | | | Summary: Change-Id: If6ee98e4a723b643bc37254fc6ef8b3812db16da Reviewers: rampitec Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62720 Change-Id: Id547ef152b2f92b24dc1c0efbf7e4467c4fb4b6e llvm-svn: 362390
* Include what you use in HexagonInstPrinter.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonInstPrinter.cpp was not using any APIs from HexagonAsmPrinter.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: 362389
* Include what you use in HexagonAsmPrinter.hDmitri Gribenko2019-06-031-1/+0
| | | | llvm-svn: 362388
* Include what you use in HexagonMCInstrInfo.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCInstrInfo.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: 362387
* Include what you use in HexagonMCCodeEmitter.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCCodeEmitter.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: 362386
* Include what you use in HexagonMCCompound.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCCompound.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: 362385
* Include what you use in HexagonShuffler.cppDmitri Gribenko2019-06-031-1/+1
| | | | | | | | | | HexagonShuffler.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: 362384
* Include what you use in HexagonMCChecker.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCChecker.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: 362383
* Include what you use in HexagonMCTargetDesc.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCTargetDesc.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: 362382
* Include what you use in HexagonMCShuffler.cppDmitri Gribenko2019-06-031-1/+0
| | | | | | | | | HexagonMCShuffler.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: 362381
* [ARM] Fix recent breakage of -mfpu=none.Simon Tatham2019-06-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent change D60691 introduced a bug in clang when handling option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those options together should select Cortex-M4 but disable all use of hardware FP, but in fact, now hardware FP instructions can still be generated in that mode. The reason is because the handling of FPUVersion::NONE disables all the same feature names it used to, of which the base one is `vfp2`. But now there are further features below that, like `vfp2d16fp` and (following D60694) `fpregs`, which also need to be turned off to disable hardware FP completely. Added a tiny test which double-checks that compiling a simple FP function doesn't access the FP registers. Reviewers: SjoerdMeijer, dmgreen Reviewed By: dmgreen Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62729 llvm-svn: 362380
* 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
OpenPOWER on IntegriCloud