summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [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
* [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-032-3/+3
| | | | | | | | | | 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
* 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
* Include what you use in LanaiInstrInfo.cppDmitri Gribenko2019-06-031-3/+3
| | | | llvm-svn: 362408
* 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
* 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
* 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
* 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
* [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
* [TTI][X86] Cleanup getMaskedMemoryOpCost. NFCI.Simon Pilgrim2019-06-021-8/+11
| | | | | | Prep work before resurrecting D61257. llvm-svn: 362335
* [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-021-36/+0
| | | | | | | | | | 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
* [X86] Add the SSE versions of PMULLW and PMULLD to isAssociativeAndCommutative.Craig Topper2019-06-021-0/+2
| | | | llvm-svn: 362309
* [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
* [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
* [COFF, ARM64] Add CodeView register mappingTom Tan2019-05-311-5/+172
| | | | | | | | | | | | | | | | 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
* AMDGPU: Fix not adding ImplicitBufferPtr as a live-inMatt Arsenault2019-05-311-1/+4
| | | | | | Fixes missing test from r293000. llvm-svn: 362275
* [AMDGPU] Use InliningThresholdMultiplier for inline hintStanislav Mekhanoshin2019-05-311-1/+2
| | | | | | | | | | | | | | AMDGPU uses multiplier 9 for the inline cost. It is taken into account everywhere except for inline hint threshold. As a result we are penalizing functions with the inline hint making them less probable to be inlined than those without the hint. Defaults are 225 for a normal function and 325 for a function with an inline hint. Currently we have effective threshold 225 * 9 = 2025 for normal functions and just 325 for those with the hint. That is fixed by this patch. Differential Revision: https://reviews.llvm.org/D62707 llvm-svn: 362239
* [PPC] Correctly adjust branch probability in PPCReduceCRLogicalsGuozhi Wei2019-05-311-6/+35
| | | | | | | | | | | | | | | | | | | | | In PPCReduceCRLogicals after splitting the original MBB into 2, the 2 impacted branches still use original branch probability. This is unreasonable. Suppose we have following code, and the probability of each successor is 50%. condc = conda || condb br condc, label %target, label %fallthrough It can be transformed to following, br conda, label %target, label %newbb newbb: br condb, label %target, label %fallthrough Since each branch has a probability of 50% to each successor, the total probability to %fallthrough is 25% now, and the total probability to %target is 75%. This actually changed the original profiling data. A more reasonable probability can be set to 70% to the false side for each branch instruction, so the total probability to %fallthrough is close to 50%. This patch assumes the branch target with two incoming edges have same edge frequency and computes new probability fore each target, and keep the total probability to original targets unchanged. Differential Revision: https://reviews.llvm.org/D62430 llvm-svn: 362237
OpenPOWER on IntegriCloud