aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveRangeEdit.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-08-15Apply llvm-prefer-register-over-unsigned from clang-tidy to LLVMDaniel Sanders1-3/+3
Summary: This clang-tidy check is looking for unsigned integer variables whose initializer starts with an implicit cast from llvm::Register and changes the type of the variable to llvm::Register (dropping the llvm:: where possible). Partial reverts in: X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister X86FixupLEAs.cpp - Some functions return unsigned and arguably should be MCRegister X86FrameLowering.cpp - Some functions return unsigned and arguably should be MCRegister HexagonBitSimplify.cpp - Function takes BitTracker::RegisterRef which appears to be unsigned& MachineVerifier.cpp - Ambiguous operator==() given MCRegister and const Register PPCFastISel.cpp - No Register::operator-=() PeepholeOptimizer.cpp - TargetInstrInfo::optimizeLoadInstr() takes an unsigned& MachineTraceMetrics.cpp - MachineTraceMetrics lacks a suitable constructor Manual fixups in: ARMFastISel.cpp - ARMEmitLoad() now takes a Register& instead of unsigned& HexagonSplitDouble.cpp - Ternary operator was ambiguous between unsigned/Register HexagonConstExtenders.cpp - Has a local class named Register, used llvm::Register instead of Register. PPCFastISel.cpp - PPCEmitLoad() now takes a Register& instead of unsigned& Depends on D65919 Reviewers: arsenm, bogner, craig.topper, RKSimon Reviewed By: arsenm Subscribers: RKSimon, craig.topper, lenary, aemerson, wuzish, jholewinski, MatzeB, qcolombet, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, wdng, nhaehnle, sbc100, jgravelle-google, kristof.beyls, hiraditya, aheejin, kbarton, fedor.sergeev, javed.absar, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, tpr, PkmX, jocewei, jsji, Petar.Avramovic, asbirlea, Jim, s.egerton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65962 llvm-svn: 369041
2019-08-01Finish moving TargetRegisterInfo::isVirtualRegister() and friends to ↵Daniel Sanders1-3/+3
llvm::Register as started by r367614. NFC llvm-svn: 367633
2019-06-27[LiveRangeEdit] Fix build failure caused by the rL364536Djordje Todorovic1-1/+1
llvm-svn: 364549
2019-06-27[Backend] Keep call site info valid through the backendDjordje Todorovic1-0/+2
Handle call instruction replacements and deletions in order to preserve valid state of the call site info of the MachineFunction. NOTE: If the call site info is enabled for a new target, the assertion from the MachineFunction::DeleteMachineInstr() should help to locate places where the updateCallSiteInfo() should be called in order to preserve valid state of the call site info. ([10/13] Introduce the debug entry values.) Co-authored-by: Ananth Sowda <asowda@cisco.com> Co-authored-by: Nikola Prica <nikola.prica@rt-rk.com> Co-authored-by: Ivan Baev <ibaev@cisco.com> Differential Revision: https://reviews.llvm.org/D61062 llvm-svn: 364536
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-05-14Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen1-8/+8
The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
2018-01-10LiveRangeEdit: Inline markDeadRemat() into only user; NFCMatthias Braun1-1/+1
This function was only called from a single place in which we didn't even need the `if (DeadRemats)` check. llvm-svn: 322230
2018-01-10LiveRangeEdit: Simplify code; NFCMatthias Braun1-12/+14
Simplify the code slightly: Instead of creating empty subranges in one case and immediately removing them, do not create them in the first place. llvm-svn: 322226
2017-12-13Rename LiveIntervalAnalysis.h to LiveIntervals.hMatthias Braun1-1/+1
Headers/Implementation files should be named after the class they declare/define. Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"` in favor of `class LiveIntarvals;` llvm-svn: 320546
2017-11-28[CodeGen] Rename functions PrintReg* to printReg*Francis Visoiu Mistrih1-1/+1
LLVM Coding Standards: Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). Differential Revision: https://reviews.llvm.org/D40416 llvm-svn: 319168
2017-11-08Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layeringDavid Blaikie1-1/+1
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
2017-02-02[LiveRangeEdit] Don't mess up with LiveInterval when a new vreg is created.Quentin Colombet1-3/+10
In r283838, we added the capability of splitting unspillable register. When doing so we had to make sure the split live-ranges were also unspillable and we did that by marking the related live-ranges in the delegate method that is called when a new vreg is created. However, by accessing the live-range there, we also triggered their lazy computation (LiveIntervalAnalysis::getInterval) which is not what we want in general. Indeed, later code in LiveRangeEdit is going to build the live-ranges this lazy computation may mess up that computation resulting in assertion failures. Namely, the createEmptyIntervalFrom method expect that the live-range is going to be empty, not computed. Thanks to Mikael Holmén <mikael.holmen@ericsson.com> for noticing and reporting the problem. llvm-svn: 293934
2016-12-16Implement LaneBitmask::any(), use it to replace !none(), NFCIKrzysztof Parzyszek1-1/+1
llvm-svn: 289974
2016-12-15[LiveRangeEdit] Change eliminateDeadDef assert to if condition.Geoff Berry1-4/+5
The assert could potentially fire (though no cases have been encountered), so just check that the instruction we're handling specially for rematerialization only has one def to begin with. Reviewed by Wei Mi over email. llvm-svn: 289861
2016-12-15Extract LaneBitmask into a separate typeKrzysztof Parzyszek1-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
2016-12-12[LiveRangeEdit] Add assert string and descriptive comment.Geoff Berry1-1/+3
llvm-svn: 289456
2016-11-29[LiveRangeEdit] Handle instructions with no defs correctly.Geoff Berry1-1/+2
Summary: The code in LiveRangeEdit::eliminateDeadDef() that computes isOrigDef doesn't handle instructions in which operand 0 is not a def (e.g. KILL) correctly. Add a check that operand 0 is a def before doing the rest of the isOrigDef computation. Reviewers: qcolombet, MatzeB, wmi Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D27174 llvm-svn: 288189
2016-10-28MachineRegisterInfo: Remove unused arg from isConstantPhysReg(); NFCMatthias Braun1-1/+1
llvm-svn: 285423
2016-10-11[RegAllocGreedy] Attempt to split unspillable live intervalsDylan McKay1-0/+3
Summary: Previously, when allocating unspillable live ranges, we would never attempt to split. We would always bail out and try last ditch graph recoloring. This patch changes this by attempting to split all live intervals before performing recoloring. This fixes LLVM bug PR14879. I can't add test cases for any backends other than AVR because none of them have small enough register classes to trigger the bug. Reviewers: qcolombet Subscribers: MatzeB Differential Revision: https://reviews.llvm.org/D25070 llvm-svn: 283838
2016-08-24Create subranges for new intervals resulting from live interval splittingKrzysztof Parzyszek1-0/+10
The register allocator can split a live interval of a register into a set of smaller intervals. After the allocation of registers is complete, the rewriter will modify the IR to replace virtual registers with the corres- ponding physical registers. At this stage, if a register corresponding to a subregister of a virtual register is used, the rewriter will check if that subregister is undefined, and if so, it will add the <undef> flag to the machine operand. The function verifying liveness of the subregis- ter would assume that it is undefined, unless any of the subranges of the live interval proves otherwise. The problem is that the live intervals created during splitting do not have any subranges, even if the original parent interval did. This could result in the <undef> flag placed on a register that is actually defined. Differential Revision: http://reviews.llvm.org/D21189 llvm-svn: 279625
2016-07-08Allow dead insts to be kept in DeadRemat only when they are rematerializable.Wei Mi1-8/+11
Because isReallyTriviallyReMaterializableGeneric puts many limits on rematerializable instructions, this fix can prevent instructions with tied virtual operands and instructions with virtual register uses from being kept in DeadRemat, so as to workaround the live interval consistency problem for the dummy instructions kept in DeadRemat. But we still need to fix the live interval consistency problem. This patch is just a short time relieve. PR28464 has been filed as a reminder. Differential Revision: http://reviews.llvm.org/D19486 llvm-svn: 274928
2016-06-30CodeGen: Use MachineInstr& in TargetInstrInfo, NFCDuncan P. N. Exon Smith1-4/+4
This is mostly a mechanical change to make TargetInstrInfo API take MachineInstr& (instead of MachineInstr* or MachineBasicBlock::iterator) when the argument is expected to be a valid MachineInstr. This is a general API improvement. Although it would be possible to do this one function at a time, that would demand a quadratic amount of churn since many of these functions call each other. Instead I've done everything as a block and just updated what was necessary. This is mostly mechanical fixes: adding and removing `*` and `&` operators. The only non-mechanical change is to split ARMBaseInstrInfo::getOperandLatencyImpl out from ARMBaseInstrInfo::getOperandLatency. Previously, the latter took a `MachineInstr*` which it updated to the instruction bundle leader; now, the latter calls the former either with the same `MachineInstr&` or the bundle leader. As a side effect, this removes a bunch of MachineInstr* to MachineBasicBlock::iterator implicit conversions, a necessary step toward fixing PR26753. Note: I updated WebAssembly, Lanai, and AVR (despite being off-by-default) since it turned out to be easy. I couldn't run tests for AVR since llc doesn't link with it turned on. llvm-svn: 274189
2016-06-09[LiveRangeEdit] Fix a crash in eliminateDeadDef.Quentin Colombet1-1/+6
When we delete a live-range, we check if that live-range is the origin of others to keep it around for rematerialization. For that we check that the instruction we are about to remove is the same as the definition of the VNI of the original live-range. If this is the case, we just shrink the live-range to an empty one. Now, when we try to delete one of the children of such live-range (product of splitting), we do the same check. However, now the original live-range is empty and there is no way we can access the VNI to check its definition, and we crash. When we cannot get the VNI for the original live-range, that means we are not in the presence of the original definition. Thus, this check does not need to happen in that case and the crash is sloved! This bug was introduced in r266162 | wmi | 2016-04-12 20:08:27. It affects every target that uses the greedy register allocator. To happen, we need to delete both a the original instruction and its split products, in that order. This is likely to happen when rematerialization comes into play. Trying to produce a more robust test case. Will follow in a coming commit. This fixes llvm.org/PR27983. rdar://problem/26651519 llvm-svn: 272314
2016-05-10[foldMemoryOperand()] Pass LiveIntervals to enable liveness check.Jonas Paulsson1-1/+1
SystemZ (and probably other targets as well) can fold a memory operand by changing the opcode into a new instruction that as a side-effect also clobbers the CC-reg. In order to do this, liveness of that reg must first be checked. When LIS is passed, getRegUnit() can be called on it and the right LiveRange is computed on demand. Reviewed by Matthias Braun. http://reviews.llvm.org/D19861 llvm-svn: 269026
2016-04-15Don't skip splitSeparateComponents in eliminateDeadDefs for ↵Wei Mi1-5/+1
HoistSpillHelper::hoistAllSpills. Because HoistSpillHelper::hoistAllSpills is called in postOptimization, before the patch we didn't want LiveRangeEdit::eliminateDeadDefs to call splitSeparateComponents and generate unassigned new vregs. However, skipping splitSeparateComponents will make verify-machineinstrs unhappy, so I remove the early return, and use HoistSpillHelper::LRE_DidCloneVirtReg to assign physreg/stackslot for those new vregs. In addition, some code reorganization to make class HoistSpillHelper privately inheriting from LiveRangeEdit::Delegate possible. This is to be consistent with class RAGreedy and class RegisterCoalescer. Differential Revision: http://reviews.llvm.org/D19142 llvm-svn: 266489
2016-04-13Recommit r265547, and r265610,r265639,r265657 on top of it, plusWei Mi1-23/+50
two fixes with one about error verify-regalloc reported, and another about live range update of phi after rematerialization. r265547: Replace analyzeSiblingValues with new algorithm to fix its compile time issue. The patch is to solve PR17409 and its duplicates. analyzeSiblingValues is a N x N complexity algorithm where N is the number of siblings generated by reg splitting. Although it causes siginificant compile time issue when N is large, it is also important for performance since it removes redundent spills and enables rematerialization. To solve the compile time issue, the patch removes analyzeSiblingValues and replaces it with lower cost alternatives containing two parts. The first part creates a new spill hoisting method in postOptimization of register allocation. It does spill hoisting at once after all the spills are generated instead of inside every instance of selectOrSplit. The second part queries the define expr of the original register for rematerializaiton and keep it always available during register allocation even if it is already dead. It deletes those dead instructions only in postOptimization. With the two parts in the patch, it can remove analyzeSiblingValues without sacrificing performance. Patches on top of r265547: r265610 "Fix the compare-clang diff error introduced by r265547." r265639 "Fix the sanitizer bootstrap error in r265547." r265657 "InlineSpiller.cpp: Escap \@ in r265547. [-Wdocumentation]" Differential Revision: http://reviews.llvm.org/D15302 Differential Revision: http://reviews.llvm.org/D18934 Differential Revision: http://reviews.llvm.org/D18935 Differential Revision: http://reviews.llvm.org/D18936 llvm-svn: 266162
2016-04-08Revert r265547 "Recommit r265309 after fixed an invalid memory reference bug ↵Hans Wennborg1-43/+20
happened" It caused PR27275: "ARM: Bad machine code: Using an undefined physical register" Also reverting the following commits that were landed on top: r265610 "Fix the compare-clang diff error introduced by r265547." r265639 "Fix the sanitizer bootstrap error in r265547." r265657 "InlineSpiller.cpp: Escap \@ in r265547. [-Wdocumentation]" llvm-svn: 265790
2016-04-06Recommit r265309 after fixed an invalid memory reference bug happenedWei Mi1-20/+43
when DenseMap growed and moved memory. I verified it fixed the bootstrap problem on x86_64-linux-gnu but I cannot verify whether it fixes the bootstrap error on clang-ppc64be-linux. I will watch the build-bot result closely. Replace analyzeSiblingValues with new algorithm to fix its compile time issue. The patch is to solve PR17409 and its duplicates. analyzeSiblingValues is a N x N complexity algorithm where N is the number of siblings generated by reg splitting. Although it causes siginificant compile time issue when N is large, it is also important for performance since it removes redundent spills and enables rematerialization. To solve the compile time issue, the patch removes analyzeSiblingValues and replaces it with lower cost alternatives containing two parts. The first part creates a new spill hoisting method in postOptimization of register allocation. It does spill hoisting at once after all the spills are generated instead of inside every instance of selectOrSplit. The second part queries the define expr of the original register for rematerializaiton and keep it always available during register allocation even if it is already dead. It deletes those dead instructions only in postOptimization. With the two parts in the patch, it can remove analyzeSiblingValues without sacrificing performance. Differential Revision: http://reviews.llvm.org/D15302 llvm-svn: 265547
2016-04-04Revert r265309 and r265312 because they caused some errors I need to ↵Wei Mi1-43/+20
investigate. llvm-svn: 265317
2016-04-04Replace analyzeSiblingValues with new algorithm to fix its compileWei Mi1-20/+43
time issue. The patch is to solve PR17409 and its duplicates. analyzeSiblingValues is a N x N complexity algorithm where N is the number of siblings generated by reg splitting. Although it causes siginificant compile time issue when N is large, it is also important for performance since it removes redundent spills and enables rematerialization. To solve the compile time issue, the patch removes analyzeSiblingValues and replaces it with lower cost alternatives containing two parts. The first part creates a new spill hoisting method in postOptimization of register allocation. It does spill hoisting at once after all the spills are generated instead of inside every instance of selectOrSplit. The second part queries the define expr of the original register for rematerializaiton and keep it always available during register allocation even if it is already dead. It deletes those dead instructions only in postOptimization. With the two parts in the patch, it can remove analyzeSiblingValues without sacrificing performance. Differential Revision: http://reviews.llvm.org/D15302 llvm-svn: 265309
2016-02-27CodeGen: Take MachineInstr& in SlotIndexes and LiveIntervals, NFCDuncan P. N. Exon Smith1-10/+10
Take MachineInstr by reference instead of by pointer in SlotIndexes and the SlotIndex wrappers in LiveIntervals. The MachineInstrs here are never null, so this cleans up the API a bit. It also incidentally removes a few implicit conversions from MachineInstrBundleIterator to MachineInstr* (see PR26753). At a couple of call sites it was convenient to convert to a range-based for loop over MachineBasicBlock::instr_begin/instr_end, so I added MachineBasicBlock::instrs. llvm-svn: 262115
2015-09-25TargetRegisterInfo: Add typedef unsigned LaneBitmask and use it where ↵Matthias Braun1-1/+1
apropriate; NFC llvm-svn: 248623
2015-09-22LiveIntervalAnalysis: Factor common code into splitSeparateComponents; NFCMatthias Braun1-20/+13
llvm-svn: 248241
2015-08-10Trace copies when checking for rematerializability in spill weight calculationRobert Lougher1-1/+1
PR24139 contains an analysis of poor register allocation. One of the findings was that when calculating the spill weight, a rematerializable interval once split is no longer rematerializable. This is because the isRematerializable check in CalcSpillWeights.cpp does not follow the copies introduced by live range splitting (after splitting, the live interval register definition is a copy which is not rematerializable). Reviewers: qcolombet Differential Revision: http://reviews.llvm.org/D11686 llvm-svn: 244439
2015-06-01LiveRangeEdit: Fix liveranges not shrinking on subrange kill.Matthias Braun1-3/+18
If a dead instruction we may not only have a last-use in the main live range but also in a subregister range if subregisters are tracked. We need to partially rebuild live ranges in both cases. The testcase only broke when subregister liveness was enabled. I commited it in the current form because there is currently no flag to enable/disable subregister liveness. This fixes PR23720. llvm-svn: 238785
2015-05-19MachineInstr: Remove unused parameter.Matthias Braun1-2/+2
llvm-svn: 237726
2015-01-27MachineRegisterInfo can access TII off of the MachineFunction'sEric Christopher1-1/+1
subtarget and so doesn't need the TargetMachine or to access via getSubtargetImpl. Update all callers. llvm-svn: 227160
2015-01-21LiveIntervalAnalysis: Factor out code to update liveness on vreg def removalMatthias Braun1-15/+5
This cleans up code and is more in line with the general philosophy of modifying LiveIntervals through LiveIntervalAnalysis instead of changing them directly. This also fixes a case where SplitEditor::removeBackCopies() would miss the subregister ranges. llvm-svn: 226690
2015-01-21LiveIntervalAnalysis: Factor out code to update liveness on physreg def removalMatthias Braun1-9/+2
This cleans up code and is more in line with the general philosophy of modifying LiveIntervals through LiveIntervalAnalysis instead of changing them directly. llvm-svn: 226687
2014-12-24LiveRangeEdit: Check for completely empy subranges after removing ValNos.Matthias Braun1-0/+1
Completely empty subranges are not allowed and must be removed when subreg liveness is enabled. llvm-svn: 224804
2014-12-11LiveInterval: Use range based for loops for subregister ranges.Matthias Braun1-4/+3
llvm-svn: 223991
2014-12-10LiveInterval: Use more range based for loops for value numbers and segments.Matthias Braun1-3/+1
llvm-svn: 223978
2014-12-10LiveRangeEdit: Adapt eliminateDeadDef() to subregister liveness.Matthias Braun1-1/+9
llvm-svn: 223882
2014-11-17Add missing semicolon from r222118.Craig Topper1-1/+1
llvm-svn: 222119
2014-11-17Move register class name strings to a single array in MCRegisterInfo to ↵Craig Topper1-2/+5
reduce static table size and number of relocation entries. Indices into the table are stored in each MCRegisterClass instead of a pointer. A new method, getRegClassName, is added to MCRegisterInfo and TargetRegisterInfo to lookup the string in the table. llvm-svn: 222118
2014-07-29Add TargetInstrInfo interface isAsCheapAsAMove.Jiangning Liu1-1/+1
llvm-svn: 214158
2014-04-22[Modules] Remove potential ODR violations by sinking the DEBUG_TYPEChandler Carruth1-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
2014-04-14[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-4/+4
instead of comparing to nullptr. llvm-svn: 206142
2014-03-17Switch a number of loops in lib/CodeGen over to range-based for-loops, now thatOwen Anderson1-4/+2
the MachineRegisterInfo iterators are compatible with it. llvm-svn: 204075
2014-03-13Phase 2 of the great MachineRegisterInfo cleanup. This time, we're changingOwen Anderson1-2/+2
operator* on the by-operand iterators to return a MachineOperand& rather than a MachineInstr&. At this point they almost behave like normal iterators! Again, this requires making some existing loops more verbose, but should pave the way for the big range-based for-loop cleanups in the future. llvm-svn: 203865
generated by cgit v1.1 at 2025-10-08 21:20:30 +0000