summaryrefslogtreecommitdiffstats
path: root/llvm/test/CodeGen/RISCV/remat.ll
Commit message (Collapse)AuthorAgeFilesLines
* [RISCV][NFC] Fix use of missing attribute groups in testsLuís Marques2019-12-231-4/+4
|
* [MBP] Avoid tail duplication if it can't bring benefitGuozhi Wei2019-12-061-13/+12
| | | | | | | | | | | | | Current tail duplication integrated in bb layout is designed to increase the fallthrough from a BB's predecessor to its successor, but we have observed cases that duplication doesn't increase fallthrough, or it brings too much size overhead. To overcome these two issues in function canTailDuplicateUnplacedPreds I add two checks: make sure there is at least one duplication in current work set. the number of duplication should not exceed the number of successors. The modification in hasBetterLayoutPredecessor fixes a bug that potential predecessor must be at the bottom of a chain. Differential Revision: https://reviews.llvm.org/D64376
* [RISCV] Switch to the Machine SchedulerLuis Marques2019-09-171-27/+27
| | | | | | | | | Most of the test changes are trivial instruction reorderings and differing register allocations, without any obvious performance impact. Differential Revision: https://reviews.llvm.org/D66973 llvm-svn: 372106
* Revert Patch from PhabricatorLuis Marques2019-09-171-27/+27
| | | | | | This reverts r372092 (git commit e38695a0255c9e7b53639f349f8101bae1ce5c04) llvm-svn: 372104
* Patch from PhabricatorLuis Marques2019-09-171-27/+27
| | | | llvm-svn: 372092
* Revert [MBP] Disable aggressive loop rotate in plain modeJordan Rupprecht2019-08-291-26/+29
| | | | | | | | This reverts r369664 (git commit 51f48295cbe8fa3a44db263b528dd9f7bae7bf9a) It causes many benchmark regressions, internally and in llvm's benchmark suite. llvm-svn: 370398
* [MBP] Disable aggressive loop rotate in plain modeGuozhi Wei2019-08-221-29/+26
| | | | | | | | | | Patch https://reviews.llvm.org/D43256 introduced more aggressive loop layout optimization which depends on profile information. If profile information is not available, the statically estimated profile information(generated by BranchProbabilityInfo.cpp) is used. If user program doesn't behave as BranchProbabilityInfo.cpp expected, the layout may be worse. To be conservative this patch restores the original layout algorithm in plain mode. But user can still try the aggressive layout optimization with -force-precise-rotation-cost=true. Differential Revision: https://reviews.llvm.org/D65673 llvm-svn: 369664
* Revert r368339 "[MBP] Disable aggressive loop rotate in plain mode"Hans Wennborg2019-08-121-26/+29
| | | | | | | | | | | | | | | | | | It caused assertions to fire when building Chromium: lib/CodeGen/LiveDebugValues.cpp:331: bool {anonymous}::LiveDebugValues::OpenRangesSet::empty() const: Assertion `Vars.empty() == VarLocs.empty() && "open ranges are inconsistent"' failed. See https://crbug.com/992871#c3 for how to reproduce. > Patch https://reviews.llvm.org/D43256 introduced more aggressive loop layout optimization which depends on profile information. If profile information is not available, the statically estimated profile information(generated by BranchProbabilityInfo.cpp) is used. If user program doesn't behave as BranchProbabilityInfo.cpp expected, the layout may be worse. > > To be conservative this patch restores the original layout algorithm in plain mode. But user can still try the aggressive layout optimization with -force-precise-rotation-cost=true. > > Differential Revision: https://reviews.llvm.org/D65673 llvm-svn: 368579
* [MBP] Disable aggressive loop rotate in plain modeGuozhi Wei2019-08-081-29/+26
| | | | | | | | | | Patch https://reviews.llvm.org/D43256 introduced more aggressive loop layout optimization which depends on profile information. If profile information is not available, the statically estimated profile information(generated by BranchProbabilityInfo.cpp) is used. If user program doesn't behave as BranchProbabilityInfo.cpp expected, the layout may be worse. To be conservative this patch restores the original layout algorithm in plain mode. But user can still try the aggressive layout optimization with -force-precise-rotation-cost=true. Differential Revision: https://reviews.llvm.org/D65673 llvm-svn: 368339
* [RISCV] Regenerate remat.ll and atomic-rmw.ll after D43256Fangrui Song2019-06-151-26/+29
| | | | llvm-svn: 363487
* [RISCV] Only mark fp as reserved if the function has a dedicated frame pointerAlex Bradbury2019-03-131-47/+49
| | | | | | | | This follows similar logic in the ARM and Mips backends, and allows the free use of s0 in functions without a dedicated frame pointer. The changes in callee-saved-gprs.ll most clearly show the effect of this patch. llvm-svn: 356063
* Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUIAna Pazos2019-01-251-40/+39
| | | | | | This reapplies commit r352010 with RISC-V test fixes. llvm-svn: 352237
* [RISCV] Set CostPerUse for registersSameer AbuAsal2018-05-231-9/+9
| | | | | | | | | | | | | | | | | | | Summary: Set CostPerUse higher for registers that are not used in the compressed instruction set. This will influence the greedy register allocator to reduce the use of registers that can't be encoded in 16 bit instructions. This affects register allocation even when compressed instruction isn't targeted, we see no major negative codegen impact. Reviewers: asb Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, apazos, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang Differential Revision: https://reviews.llvm.org/D47039 llvm-svn: 333132
* [RISCV] Set isReMaterializable on ADDI and LUI instructionsAlex Bradbury2018-05-171-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | The isReMaterlizable flag is somewhat confusing, unlike most other instruction flags it is currently interpreted as a hint (mightBeRematerializable would be a better name). While LUI is always rematerialisable, for an instruction like ADDI it depends on its operands. TargetInstrInfo::isTriviallyReMaterializable will call TargetInstrInfo::isReallyTriviallyReMaterializable, which in turn calls TargetInstrInfo::isReallyTriviallyReMaterializableGeneric. We rely on the logic in the latter to pick out instances of ADDI that really are rematerializable. The isReMaterializable flag does make a difference on a variety of test programs. The recently committed remat.ll test case demonstrates how stack usage is reduce and a unnecessary lw/sw can be removed. Stack usage in the Proc0 function in dhrystone reduces from 192 bytes to 112 bytes. For the sake of completeness, this patch also implements RISCVRegisterInfo::isConstantPhysReg. Although this is called from a number of places, it doesn't seem to result in different codegen for any programs I've thrown at it. However, it is called in the rematerialisation codepath and it seems sensible to implement something correct here. Differential Revision: https://reviews.llvm.org/D46182 llvm-svn: 332617
* [RISCV] Add remat.ll test caseAlex Bradbury2018-04-271-0/+209
This test case demonstrates suboptimal codegen due to the fact that simple constants aren't recognised as rematerialisable. llvm-svn: 331028
OpenPOWER on IntegriCloud