summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/RegisterScavenging.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-02-211-3/+11
| | | | | | other minor fixes (NFC). llvm-svn: 295773
* CodeGen: Add/Factor out LiveRegUnits class; NFCIMatthias Braun2017-01-201-59/+8
| | | | | | | | | | | | | This is a set of register units intended to track register liveness, it is similar in spirit to LivePhysRegs. You can also think of this as the liveness tracking parts of the RegisterScavenger factored out into an own class. This was proposed in http://llvm.org/PR27609 Differential Revision: http://reviews.llvm.org/D21916 llvm-svn: 292542
* CodeGen: Assert that liveness is up to date when reading block live-ins.Matthias Braun2017-01-051-5/+0
| | | | | | | | | | | | | | | | | Add an assert that checks whether liveins are up to date before they are used. - Do not print liveins into .mir files anymore in situations where they are out of date anyway. - The assert in the RegisterScavenger is superseded by the new one in livein_begin(). - Skip parts of the liveness updating logic in IfConversion.cpp when liveness isn't tracked anymore (just enough to avoid hitting the new assert()). Differential Revision: https://reviews.llvm.org/D27562 llvm-svn: 291169
* Implement LaneBitmask::any(), use it to replace !none(), NFCIKrzysztof Parzyszek2016-12-161-1/+1
| | | | llvm-svn: 289974
* Extract LaneBitmask into a separate typeKrzysztof Parzyszek2016-12-151-1/+1
| | | | | | | | | | | | Specifically avoid implicit conversions from/to integral types to avoid potential errors when changing the underlying type. For example, a typical initialization of a "full" mask was "LaneMask = ~0u", which would result in a value of 0x00000000FFFFFFFF if the type was extended to uint64_t. Differential Revision: https://reviews.llvm.org/D27454 llvm-svn: 289820
* [RegisterScavenger] Remove aliasing registers of operands from the candidate setSilviu Baranga2016-09-061-1/+2
| | | | | | | | | | | | | | | | | | | | Summary: In addition to not including the register operand of the current instruction also don't include any aliasing registers. We can't consider these as candidates because using them will clobber the corresponding register operand of the current instruction. This change doesn't include a test case and it would probably be difficult to produce a stable one since the bug depends on the results of register allocation. Reviewers: MatzeB, qcolombet, hfinkel Subscribers: hfinkel, llvm-commits Differential Revision: https://reviews.llvm.org/D24130 llvm-svn: 280698
* Revert "RegScavenging: Add scavengeRegisterBackwards()"Matthias Braun2016-08-191-164/+103
| | | | | | | | | | | The ppc64 multistage bot fails on this. This reverts commit r279124. Also Revert "CodeGen: Add/Factor out LiveRegUnits class; NFCI" because it depends on the previous change This reverts commit r279171. llvm-svn: 279199
* CodeGen: Add/Factor out LiveRegUnits class; NFCIMatthias Braun2016-08-181-60/+9
| | | | | | | | | | | | | This is a set of register units intended to track register liveness, it is similar in spirit to LivePhysRegs. You can also think of this as the liveness tracking parts of the RegisterScavenger factored out into an own class. This was proposed in http://llvm.org/PR27609 Differential Revision: http://reviews.llvm.org/D21916 llvm-svn: 279171
* RegScavenging: Add scavengeRegisterBackwards()Matthias Braun2016-08-181-46/+158
| | | | | | | | | | | | | | | | Re-apply r276044 with off-by-1 instruction fix for the reload placement. This is a variant of scavengeRegister() that works for enterBasicBlockEnd()/backward(). The benefit of the backward mode is that it is not affected by incomplete kill flags. This patch also changes PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register scavenger in backwards mode. Differential Revision: http://reviews.llvm.org/D21885 llvm-svn: 279124
* MachineFunction: Return reference for getFrameInfo(); NFCMatthias Braun2016-07-281-2/+2
| | | | | | | getFrameInfo() never returns nullptr so we should use a reference instead of a pointer. llvm-svn: 277017
* Revert "RegScavenging: Add scavengeRegisterBackwards()"Matthias Braun2016-07-201-159/+46
| | | | | | | | | Reverting this commit for now as it seems to be causing failures on test-suite tests on the clang-ppc64le-linux-lnt bot. This reverts commit r276044. llvm-svn: 276068
* RegScavenging: Add scavengeRegisterBackwards()Matthias Braun2016-07-191-46/+159
| | | | | | | | | | | | | | This is a variant of scavengeRegister() that works for enterBasicBlockEnd()/backward(). The benefit of the backward mode is that it is not affected by incomplete kill flags. This patch also changes PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register scavenger in backwards mode. Differential Revision: http://reviews.llvm.org/D21885 llvm-svn: 276044
* RegisterScavenger: Introduce backward() mode.Matthias Braun2016-07-191-23/+84
| | | | | | | | | | | | | | | | This adds two pieces: - RegisterScavenger:::enterBasicBlockEnd() which behaves similar to enterBasicBlock() but starts tracking at the end of the basic block. - A RegisterScavenger::backward() method. It is subtly different from the existing unprocess() method which only considers uses with the kill flag set: If a value is dead at the end of a basic block with a last use inside the basic block, unprocess() will fail to mark it as live. However we cannot change/fix this behaviour because unprocess() needs to perform the exact reverse operation of forward(). Differential Revision: http://reviews.llvm.org/D21873 llvm-svn: 276043
* CodeGen: Use MachineInstr& in RegisterScavenging, NFCDuncan P. N. Exon Smith2016-07-081-16/+15
| | | | | | | Prefer MachineInstr& in order to avoid implicit conversions from MachineInstrBundleIterator to MachineInstr*. llvm-svn: 274888
* RegisterScavenging: Code cleanup; NFCMatthias Braun2016-06-301-40/+26
| | | | | | | | | | | | | - Use range based for loops - No need for some !Reg checks: isPhysicalRegister() reports false for NoRegister anyway - Do not repeat function name in documentation comment. - Do not repeat documentation comment in implementation when we already have one at the declaration. - Factor some common subexpressions out. - Change file comments to use doxygen syntax. llvm-svn: 274194
* Use report_fatal_error after allKrzysztof Parzyszek2016-05-201-1/+1
| | | | | | | | Depending on the compiler used to build LLVM, llvm_unreachable can either expand to a call to abort(), or to a __builtin_unreachable. The latter does not have a predictable behavior at runtime. llvm-svn: 270260
* Fix error reporting in register scavenger (lack of emergency spill slot)Krzysztof Parzyszek2016-05-201-7/+4
| | | | | | | | - Do not store Twine objects. - Remove report_fatal_error, since llvm_unreachable does terminate the program in release mode. llvm-svn: 270233
* Correction to r270219: fix detection of invalid frame indexKrzysztof Parzyszek2016-05-201-1/+2
| | | | llvm-svn: 270220
* Skip entries with invalid indexes in the search loop in register scavengerKrzysztof Parzyszek2016-05-201-1/+4
| | | | llvm-svn: 270219
* When looking for a spill slot in reg scavenger, find one that matches RCKrzysztof Parzyszek2016-05-181-7/+38
| | | | | | | | | | | | When looking for an available spill slot, the register scavenger would stop after finding the first one with no register assigned to it. That slot may have size and alignment that do not meet the requirements of the register that is to be spilled. Instead, find an available slot that is the closest in size and alignment to one that is needed to spill a register from RC. Differential Revision: http://reviews.llvm.org/D20295 llvm-svn: 269969
* RegisterScavenger: Take a reference as enterBasicBlock() argument.Matthias Braun2016-04-061-7/+4
| | | | | | | Make it obvious that the argument cannot be nullptr. Remove an unnecessary nullptr check in initRegState. llvm-svn: 265511
* TargetRegisterInfo: Add typedef unsigned LaneBitmask and use it where ↵Matthias Braun2015-09-251-2/+2
| | | | | | apropriate; NFC llvm-svn: 248623
* Save LaneMask with livein registersMatthias Braun2015-09-091-5/+8
| | | | | | | | | | | | | | | | | With subregister liveness enabled we can detect the case where only parts of a register are live in, this is expressed as a 32bit lanemask. The current code only keeps registers in the live-in list and therefore enumerated all subregisters affected by the lanemask. This turned out to be too conservative as the subregister may also cover additional parts of the lanemask which are not live. Expressing a given lanemask by enumerating a minimum set of subregisters is computationally expensive so the best solution is to simply change the live-in list to store the lanemasks as well. This will reduce memory usage for targets using subregister liveness and slightly increase it for other targets Differential Revision: http://reviews.llvm.org/D12442 llvm-svn: 247171
* MachineBasicBlock: Add liveins() method returning an iterator_rangeMatthias Braun2015-08-241-3/+2
| | | | llvm-svn: 245895
* [RegisterScavenger] Fix handling of predicated instructionsTobias Edler von Koch2015-06-091-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The RegisterScavenger explicitly ignores <kill> flags on operands of predicated instructions and therefore assumes that such registers remain live. When it then scavenges such a register, it inserts a spill of this (killed) register. This is invalid code and gets flagged up by the verifier. Nowadays kill flags are set correctly on predicated instructions. This patch makes the Scavenger respect them. The bug has so far only been triggered by an internal pass, so I don't have a test case unfortunately. Fixes PR23119. Reviewers: hfinkel, tobiasvk_caf Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9039 llvm-svn: 239439
* MachineFrameInfo: Simplify pristine register calculation.Matthias Braun2015-05-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | About pristine regsiters: Pristine registers "hold a value that is useless to the current function, but that must be preserved - they are callee saved registers that have not been saved." This concept saves compile time as it frees the prologue/epilogue inserter from adding every such register to every basic blocks live-in list. However the current code in getPristineRegs is formulated in a complicated way: Inside the function prologue and epilogue all callee saves are considered pristine, while in the rest of the code only the non-saved ones are considered pristine. This requires logic to differentiate between prologue/epilogue and the rest and in the presence of shrink-wrapping this even becomes complicated/expensive. It's also unnecessary because the prologue epilogue inserters already mark callee-save registers that are saved/restores properly in the respective blocks in the prologue/epilogue (see updateLiveness() in PrologueEpilogueInserter.cpp). So only declaring non-saved/restored callee saved registers as pristine just works. Differential Revision: http://reviews.llvm.org/D10101 llvm-svn: 238524
* Grab the subtarget and subtarget dependent variables off ofEric Christopher2014-10-141-4/+2
| | | | | | MachineFunction rather than TargetMachine. llvm-svn: 219671
* Changed the liveness tracking in the RegisterScavengerPedro Artigas2014-08-041-60/+64
| | | | | | | | to use register units instead of registers. reviewed by Jakob Stoklund Olesen. llvm-svn: 214798
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+3
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* [Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth2014-04-221-1/+2
| | | | | | | | | | | | define below all header includes in the lib/CodeGen/... tree. While the current modules implementation doesn't check for this kind of ODR violation yet, it is likely to grow support for it in the future. It also removes one layer of macro pollution across all the included headers. Other sub-trees will follow. llvm-svn: 206837
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-141-5/+5
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* Make consistent use of MCPhysReg instead of uint16_t throughout the tree.Craig Topper2014-04-041-1/+1
| | | | llvm-svn: 205610
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-4/+4
| | | | | | Remove the old functions. llvm-svn: 202636
* RegScavenger should not exclude undef usesHal Finkel2013-07-111-1/+1
| | | | | | | | | | | | | | When computing currently-live registers, the register scavenger excludes undef uses. As a result, undef uses are ignored when computing the restore points of registers spilled into the emergency slots. While the register scavenger normally excludes from consideration, when scavenging, registers used by the current instruction, we need to not exclude undef uses. Otherwise, we might end up requiring more emergency spill slots than we have (in the case where the undef use *is* the currently-spilled register). Another bug found by llvm-stress. llvm-svn: 186067
* Use SmallVectorImpl instead of SmallVector for iterators and references to ↵Craig Topper2013-07-031-4/+4
| | | | | | avoid specifying the vector size unnecessarily. llvm-svn: 185512
* Simplify logic now that r182490 is in place. No functional change intended.Chad Rosier2013-05-221-5/+4
| | | | llvm-svn: 182531
* Reapply r178845 with fix - Fix bug in PEI's virtual-register scavengingHal Finkel2013-04-051-22/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes PEI as previously described, but correctly handles the case where the instruction defining the virtual register to be scavenged is the first in the block. Arnold provided me with a bugpoint-reduced test case, but even that seems too large to use as a regression test. If I'm successful in cleaning it up then I'll commit that as well. Original commit message: This change fixes a bug that I introduced in r178058. After a register is scavenged using one of the available spills slots the instruction defining the virtual register needs to be moved to after the spill code. The scavenger has already processed the defining instruction so that registers killed by that instruction are available for definition in that same instruction. Unfortunately, after this, the scavenger needs to iterate through the spill code and then visit, again, the instruction that defines the now-scavenged register. In order to avoid confusion, the register scavenger needs the ability to 'back up' through the spill code so that it can again process the instructions in the appropriate order. Prior to this fix, once the scavenger reached the just-moved instruction, it would assert if it killed any registers because, having already processed the instruction, it believed they were undefined. Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar for diagnosing the problem and testing this fix. llvm-svn: 178919
* Revert r178845 - Fix bug in PEI's virtual-register scavengingHal Finkel2013-04-051-51/+22
| | | | | | | | | | | | | | | | | | | | | | Reverting because this breaks one of the LTO builders. Original commit message: This change fixes a bug that I introduced in r178058. After a register is scavenged using one of the available spills slots the instruction defining the virtual register needs to be moved to after the spill code. The scavenger has already processed the defining instruction so that registers killed by that instruction are available for definition in that same instruction. Unfortunately, after this, the scavenger needs to iterate through the spill code and then visit, again, the instruction that defines the now-scavenged register. In order to avoid confusion, the register scavenger needs the ability to 'back up' through the spill code so that it can again process the instructions in the appropriate order. Prior to this fix, once the scavenger reached the just-moved instruction, it would assert if it killed any registers because, having already processed the instruction, it believed they were undefined. Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar for diagnosing the problem and testing this fix. llvm-svn: 178916
* Fix bug in PEI's virtual-register scavengingHal Finkel2013-04-051-22/+51
| | | | | | | | | | | | | | | | | | | | This change fixes a bug that I introduced in r178058. After a register is scavenged using one of the available spills slots the instruction defining the virtual register needs to be moved to after the spill code. The scavenger has already processed the defining instruction so that registers killed by that instruction are available for definition in that same instruction. Unfortunately, after this, the scavenger needs to iterate through the spill code and then visit, again, the instruction that defines the now-scavenged register. In order to avoid confusion, the register scavenger needs the ability to 'back up' through the spill code so that it can again process the instructions in the appropriate order. Prior to this fix, once the scavenger reached the just-moved instruction, it would assert if it killed any registers because, having already processed the instruction, it believed they were undefined. Unfortunately, I don't yet have a small test case. Thanks to Pranav Bhandarkar for diagnosing the problem and testing this fix. llvm-svn: 178845
* Fix target-customized spilling in the register scavengerHal Finkel2013-03-271-1/+1
| | | | | | | | | | | | This is a follow-up to r178073 (which should actually make target-customized spilling work again). I still don't have a regression test for this (but it would be good to have one; Thumb 1 and Mips16 use this callback as well). Patch by Richard Sandiford. llvm-svn: 178137
* Fix the register scavenger for targets that provide custom spillingHal Finkel2013-03-261-2/+5
| | | | | | | | | | | As pointed out by Richard Sandiford, my recent updates to the register scavenger broke targets that use custom spilling (because the new code assumed that if there were no valid spill slots, than spilling would be impossible). I don't have a test case, but it should be possible to create one for Thumb 1, Mips 16, etc. llvm-svn: 178073
* Update PEI's virtual-register-based scavenging to support multiple ↵Hal Finkel2013-03-261-2/+2
| | | | | | | | | | | | | | | | | | | simultaneous mappings The previous algorithm could not deal properly with scavenging multiple virtual registers because it kept only one live virtual -> physical mapping (and iterated through operands in order). Now we don't maintain a current mapping, but rather use replaceRegWith to completely remove the virtual register as soon as the mapping is established. In order to allow the register scavenger to return a physical register killed by an instruction for definition by that same instruction, we now call RS->forward(I) prior to eliminating virtual registers defined in I. This requires a minor update to forward to ignore virtual registers. These new features will be tested in forthcoming commits. llvm-svn: 178058
* Fix comparison of mixed signednessHal Finkel2013-03-231-1/+1
| | | | | | | | | | | 177774 broke the lld-x86_64-darwin11 builder; error: error: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long') for (SI = 0; SI < Scavenged.size(); ++SI) ~~ ^ ~~~~~~~~~~~~~~~~ Fix this by making SI also unsigned. llvm-svn: 177780
* Allow the register scavenger to spill multiple registersHal Finkel2013-03-221-13/+28
| | | | | | | | | | | | | | | | | | This patch lets the register scavenger make use of multiple spill slots in order to guarantee that it will be able to provide multiple registers simultaneously. To support this, the RS's API has changed slightly: setScavengingFrameIndex / getScavengingFrameIndex have been replaced by addScavengingFrameIndex / isScavengingFrameIndex / getScavengingFrameIndices. In forthcoming commits, the PowerPC backend will use this capability in order to implement the spilling of condition registers, and some special-purpose registers, without relying on r0 being reserved. In some cases, spilling these registers requires two GPRs: one for addressing and one to hold the value being transferred. llvm-svn: 177774
* Remove ScavengedRC from RegisterScavengingHal Finkel2013-03-221-3/+0
| | | | | | | ScavengedRC was a dead private variable (set, but not otherwise used). No functionality change intended. llvm-svn: 177708
* [PEI] Pass the frame index operand number to the eliminateFrameIndex function.Chad Rosier2013-01-311-2/+16
| | | | | | | Each target implementation was needlessly recomputing the index. Part of rdar://13076458 llvm-svn: 174083
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-2/+2
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Remove unneeded #includes.Jakub Staszak2012-11-261-4/+0
| | | | llvm-svn: 168608
* [reg scavenger] Fix the isUsed/isAliasUsed functions so as to not report a falseChad Rosier2012-11-151-1/+1
| | | | | | | | | | | | | | | | positive. In this particular case, R6 was being spilled by the register scavenger when it was in fact dead. The isUsed function reported R6 as used because the R6_R7 alias was reserved (due to the fact that we've reserved R7 as the FP). The solution is to only check if the original register (i.e., R6) isReserved and not the aliases. The aliases are only checked to make sure they're available. The test case is derived from one of the nightly tester benchmarks and is rather intractable and difficult to reproduce, so I haven't included it. rdar://12592448 llvm-svn: 168054
* Switch most getReservedRegs() clients to the MRI equivalent.Jakob Stoklund Olesen2012-10-151-5/+2
| | | | | | | Using the cached bit vector in MRI avoids comstantly allocating and recomputing the reserved register bit vector. llvm-svn: 165983
OpenPOWER on IntegriCloud