summaryrefslogtreecommitdiffstats
path: root/llvm/lib
Commit message (Collapse)AuthorAgeFilesLines
* Silenced a warning "implicit conversion turns string literal into bool" ↵Dmitri Gribenko2019-06-041-2/+3
| | | | | | introduced in r362473 llvm-svn: 362480
* Include what you use in PPC.hDmitri Gribenko2019-06-041-1/+0
| | | | llvm-svn: 362477
* Include what you use in PPCMachineScheduler.cppDmitri Gribenko2019-06-041-1/+3
| | | | llvm-svn: 362476
* Include what you use in PPCRegisterInfo.hDmitri Gribenko2019-06-041-1/+2
| | | | llvm-svn: 362475
* Make SwitchInstProfUpdateWrapper saferYevgeny Rouban2019-06-041-18/+39
| | | | | | | | | | | | | | | | | | | | While prof branch_weights inconsistencies are being fixed patch by patch (pass by pass) we need SwitchInstProfUpdateWrapper to be safe with respect to inconsistent metadata that can come from passes that have not been fixed yet. See the bug found by @nikic in https://reviews.llvm.org/D62126. This patch introduces one more state (called Invalid) to the wrapper class that allows users to work with the underlying SwitchInst ignoring the prof metadata changes. Created a unit test for the SwitchInstProfUpdateWrapper class. Reviewers: davidx, nikic, eraman, reames, chandlerc Reviewed By: davidx Differential Revision: https://reviews.llvm.org/D62656 llvm-svn: 362473
* [DAGCombine] Match a pattern where a wide type scalar value is stored by ↵QingShan Zhang2019-06-041-0/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | several narrow stores This opportunity is found from spec 2017 557.xz_r. And it is used by the sha encrypt/decrypt. See sha-2/sha512.c static void store64(u64 x, unsigned char* y) { for(int i = 0; i != 8; ++i) y[i] = (x >> ((7-i) * 8)) & 255; } static u64 load64(const unsigned char* y) { u64 res = 0; for(int i = 0; i != 8; ++i) res |= (u64)(y[i]) << ((7-i) * 8); return res; } The load64 has been implemented by https://reviews.llvm.org/D26149 This patch is trying to implement the store pattern. Match a pattern where a wide type scalar value is stored by several narrow stores. Fold it into a single store or a BSWAP and a store if the targets supports it. Assuming little endian target: i8 *p = ... i32 val = ... p[0] = (val >> 0) & 0xFF; p[1] = (val >> 8) & 0xFF; p[2] = (val >> 16) & 0xFF; p[3] = (val >> 24) & 0xFF; > *((i32)p) = val; i8 *p = ... i32 val = ... p[0] = (val >> 24) & 0xFF; p[1] = (val >> 16) & 0xFF; p[2] = (val >> 8) & 0xFF; p[3] = (val >> 0) & 0xFF; > *((i32)p) = BSWAP(val); Differential Revision: https://reviews.llvm.org/D61843 llvm-svn: 362472
* [ARM] Turn some undefined encoding bits into 0s.Simon Tatham2019-06-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | The family of 32-bit Thumb instruction encodings that include t2ORR, t2AND and t2EOR are all listed in the ArmARM as having (0) in bit 15. The Tablegen descriptions of those instructions listed them as ?. This change tightens that up by making them into 0 + Unpredictable. In the specific case of t2ORR, we tighten it up still further by making the zero bit mandatory. This change comes from Arm v8.1-M, in which encodings with that bit equal to 1 will now be used for different instructions. Reviewers: dmgreen, samparker, SjoerdMeijer, efriedma Reviewed By: dmgreen, efriedma Subscribers: efriedma, javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60705 llvm-svn: 362470
* [SCCP] Add UnaryOperator visitor to SCCP for unary FNegCameron McInally2019-06-031-0/+26
| | | | | | Differential Revision: https://reviews.llvm.org/D62819 llvm-svn: 362449
* Propagate fmf for setcc in SDAG for select foldsMichael Berg2019-06-032-4/+8
| | | | llvm-svn: 362448
* AMDGPU: Disable stack realignment for kernelsMatt Arsenault2019-06-032-0/+14
| | | | | | | | | | | | | | | | | | | This is something of a workaround, and the state of stack realignment controls is kind of a mess. Ideally, we would be able to specify the stack is infinitely aligned on entry to a kernel. TargetFrameLowering provides multiple controls which apply at different points. The StackRealignable field is used during SelectionDAG, and for some reason distinct from this hook. StackAlignment is a single field not dependent on the function. It would probably be better to make that dependent on the calling convention, and the maximum value for kernels. Currently this doesn't really change anything, since the frame lowering mostly does its own thing. This helps avoid regressions in a future change which will rely more heavily on hasFP. llvm-svn: 362447
* [AArch64][GlobalISel] Optimize G_FCMP + G_SELECT pairs when G_SELECT is fpJessica Paquette2019-06-031-8/+96
| | | | | | | | | | | | | | | | Instead of emitting all of the test stuff for a compare when it's only used by a select, instead, just emit the compare + select. The select will use the value of NZCV correctly, so we don't need to emit all of the test instructions etc. For now, only support fp selects which use G_FCMP. Also only support condition codes which will only require one select to represent. Also add a test. Differential Revision: https://reviews.llvm.org/D62695 llvm-svn: 362446
* CFLAA: reflow comments; NFCGeorge Burgess IV2019-06-031-5/+4
| | | | llvm-svn: 362442
* [CFLGraph] Add FAdd to visitConstantExpr.Craig Topper2019-06-031-0/+1
| | | | | | | | | | | | This looks like an oversight as all the other binary operators are present. Accidentally noticed while auditing places that need FNeg handling. No test because as noted in the review it would be contrived and amount to "don't crash" Differential Revision: https://reviews.llvm.org/D62790 llvm-svn: 362441
* [X86] Fix the pattern for merge masked vcvtps2pd.Craig Topper2019-06-031-4/+1
| | | | | | | | r362199 fixed it for zero masking, but not zero masking. The load folding in the peephole pass hid the bug. This patch turns off the peephole pass on the relevant test to ensure coverage. llvm-svn: 362440
* Propagate fmf for setcc/select foldsMichael Berg2019-06-031-3/+10
| | | | | | | | | | | | | | Summary: This change facilitates propagating fmf which was placed on setcc from fcmp through folds with selects so that back ends can model this path for arithmetic folds on selects in SDAG. Reviewers: qcolombet, spatel Reviewed By: qcolombet Subscribers: nemanjai, jsji Differential Revision: https://reviews.llvm.org/D62552 llvm-svn: 362439
* [PowerPC] Look through copies for compare eliminationNemanja Ivanovic2019-06-031-1/+6
| | | | | | | | | | | | We currently miss the opportunities for optmizing comparisons in the peephole optimizer if the input is the result of a COPY since we look for record-form versions of the producing instruction. This patch simply lets the optimization peek through copies. Differential revision: https://reviews.llvm.org/D59633 llvm-svn: 362438
* TTI: Improve default costs for addrspacecastMatt Arsenault2019-06-033-5/+5
| | | | | | | | | | For some reason multiple places need to do this, and the variant the loop unroller and inliner use was not handling it. Also, introduce a new wrapper to be slightly more precise, since on AMDGPU some addrspacecasts are free, but not no-ops. llvm-svn: 362436
* [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
OpenPOWER on IntegriCloud