aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/RegisterCoalescer.cpp
AgeCommit message (Collapse)AuthorFilesLines
2015-01-08RegisterCoalescer: Do not remove IMPLICIT_DEFS if they are required for ↵Matthias Braun1-1/+7
subranges. The register coalescer used to remove implicit_defs when they are covered by the main range anyway. With subreg liveness tracking we can't do that anymore in places where the IMPLICIT_DEF is required as begin of a subregister liverange. llvm-svn: 225416
2015-01-07RegisterCoalescer: Fix valuesIdentical() in some subrange merge cases.Matthias Braun1-90/+81
I got confused and assumed SrcIdx/DstIdx of the CoalescerPair is a subregister index in SrcReg/DstReg, but they are actually subregister indices of the coalesced register that get you back to SrcReg/DstReg when applied. Fixed the bug, improved comments and simplified code accordingly. Testcase by Tom Stellard! llvm-svn: 225415
2014-12-25Silence GCC's -Wparentheses warningDavid Majnemer1-1/+1
No functionality change intended. llvm-svn: 224833
2014-12-24RegisterCoalescer: With subrange liveness there may be no RedefVNI for ↵Matthias Braun1-3/+6
unused lanes. llvm-svn: 224805
2014-12-19RegisterCoalescer: rewrite eliminateUndefCopy().Matthias Braun1-29/+64
This also fixes problems with undef copies of subregisters. I can't attach a testcase for that as none of the targets in trunk has subregister liveness tracking enabled. llvm-svn: 224560
2014-12-17RegisterCoalescer: Fix stripCopies() picking up main range instead of ↵Matthias Braun1-50/+78
subregister range This fixes a problem where stripCopies() would switch to values in the main liverange when it crossed a copy instruction. However when joining subranges we need to stay in the respective subregister ranges. llvm-svn: 224461
2014-12-17RegisterCoalescer: Sprinkle some const modifiers.Matthias Braun1-11/+12
llvm-svn: 224409
2014-12-11LiveInterval: Use range based for loops for subregister ranges.Matthias Braun1-75/+61
llvm-svn: 223991
2014-12-10LiveInterval: Use more range based for loops for value numbers and segments.Matthias Braun1-10/+9
llvm-svn: 223978
2014-12-10RegisterCoalescer: Preserve subregister liveranges.Matthias Braun1-121/+559
llvm-svn: 223888
2014-12-10LiveIntervalAnalysis: Add subregister aware variants pruneValue().Matthias Braun1-2/+2
llvm-svn: 223886
2014-12-04Simplify implementation and testcase of r223401 based on feedback from dblaikie.Adrian Prantl1-4/+2
llvm-svn: 223405
2014-12-04Debug info: If the RegisterCoalescer::reMaterializeTrivialDef() isAdrian Prantl1-1/+13
eliminating all uses of a vreg, update any DBG_VALUE describing that vreg to point to the rematerialized register instead. llvm-svn: 223401
2014-11-19RegisterCoalescer: Improve debug messagesMatthias Braun1-6/+8
- Show "Considering..." message after flipping so you actually see the final destination vreg as destination. - Add a message on final join, so you can grep for "Success" messages to obtain a list of which register got merged with which. llvm-svn: 222382
2014-11-19Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie1-1/+1
pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
2014-11-17Move register class name strings to a single array in MCRegisterInfo to ↵Craig Topper1-3/+3
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-10-09delete function names from commentsSanjay Patel1-32/+30
llvm-svn: 219444
2014-08-21Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper1-2/+2
needing to mention the size. llvm-svn: 216158
2014-08-18Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper1-2/+2
avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
2014-08-17Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper1-2/+2
needing to mention the size. llvm-svn: 215868
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-2/+2
information and update all callers. No functional change. llvm-svn: 214781
2014-07-29Add TargetInstrInfo interface isAsCheapAsAMove.Jiangning Liu1-1/+1
llvm-svn: 214158
2014-07-16[RegisterCoalescer] Moving the RegisterCoalescer subtarget hook onto the ↵Chris Bieneman1-2/+1
TargetRegisterInfo instead of the TargetSubtargetInfo. llvm-svn: 213188
2014-07-15[RegisterCoalescer] Add new subtarget hook allowing targets to opt-out of ↵Chris Bieneman1-0/+17
coalescing. The coalescer is very aggressive at propagating constraints on the register classes, and the register allocator doesn’t know how to split sub-registers later to recover. This patch provides an escape valve for targets that encounter this problem to limit coalescing. This patch also implements such for ARM to lower register pressure when using lots of large register classes. This works around PR18825. llvm-svn: 213078
2014-04-30Convert more loops to range-based equivalentsAlexey Samsonov1-3/+2
llvm-svn: 207714
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-10/+11
instead of comparing to nullptr. llvm-svn: 206142
2014-04-11[Register Coalescer] Fix wrong live-range information with rematerialization.Quentin Colombet1-0/+21
When rematerializing an instruction that defines a super register that would be used by a physical subregisters we use the related physical super register for the definition. To keep the live-range information accurate, all the defined subregisters must be marked as dead def, otherwise the register allocation may miss some interferences. Working on a reduced test-case! <rdar://problem/16582185> llvm-svn: 206060
2014-03-17Switch a number of loops in lib/CodeGen over to range-based for-loops, now thatOwen Anderson1-9/+5
the MachineRegisterInfo iterators are compatible with it. llvm-svn: 204075
2014-03-15Remove some dead assignements found by scan-buildArnaud A. de Grandmaison1-1/+0
llvm-svn: 204013
2014-03-13Phase 2 of the great MachineRegisterInfo cleanup. This time, we're changingOwen Anderson1-4/+4
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
2014-03-13Phase 1 of refactoring the MachineRegisterInfo iterators to make them suitableOwen Anderson1-2/+5
for use with C++11 range-based for-loops. The gist of phase 1 is to remove the skipInstruction() and skipBundle() methods from these iterators, instead splitting each iterator into a version that walks operands, a version that walks instructions, and a version that walks bundles. This has the result of making some "clever" loops in lib/CodeGen more verbose, but also makes their iterator invalidation characteristics much more obvious to the casual reader. (Making them concise again in the future is a good motivating case for a pre-incrementing range adapter!) Phase 2 of this undertaking with consist of removing the getOperand() method, and changing operator*() of the operand-walker to return a MachineOperand&. At that point, it should be possible to add range views for them that work as one might expect. llvm-svn: 203757
2014-03-07[C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper1-5/+5
class. llvm-svn: 203220
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-1/+0
This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-02[C++11] Replace llvm::tie with std::tie.Benjamin Kramer1-1/+1
The old implementation is no longer needed in C++11. llvm-svn: 202644
2014-03-02[C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer1-2/+2
Remove the old functions. llvm-svn: 202636
2014-01-16ReMat: fix overly cavalier attitude to sub-register indicesTim Northover1-24/+21
There are two attempted optimisations in reMaterializeTrivialDef, trying to avoid promoting the size of a register too much when rematerializing. Unfortunately, both appear to be flawed. First, we see if the original register would have worked, but this is inadequate. Consider: v1 = SOMETHING (v1 is QQ) v2:Q0 = COPY v1:Q1 (v1, v2 are QQ) ... uses of v2 In this case even though v2 *could* be used directly as the output of SOMETHING, this would set the wrong bits of the QQ register involved. The correct rematerialization must be: v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ) ... uses of v2:Q1_Q2 For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try to hunt for a class between v1 and v2 that works. Unfortunately, this is also wrong: v1 = SOMETHING (v1 is QQ) v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ) ... uses of v2 as a QQQ The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current logic would decide that v2 could be a QQ (no interest is taken in later uses). This patch, therefore, always accepts the widened register class without trying to be clever. Generally there is no penalty to this (e.g. in the common GR32 < GR64 case, expanding the width doesn't matter because it's not like you were going to do anything else with the high bits of a GR32 register). It can increase register pressure in cases like the ARM VFP regs though (multiple non-overlapping but equivalent subregisters). This situation can be spotted by the fact that both source and destination in the not-quite-coalesced pair have a sub-register index and rematerialisation is skipped in that situation. Unfortunately, no in-tree targets actually expose this as far as I can tell (there are so few isAsCheapAsAMove instructions for it to trigger on) so I've been unable to produce a test. It was exposed in our ARM64 SPEC tests though, and I will be adding a test there that we should be able to contribute soon(TM). rdar://problem/15775279 llvm-svn: 199376
2014-01-14Fix valgrind warning for gcc builds.Patrik Hagglund1-5/+4
Sorry, I don't understand why the warning is generated (a gcc bug?). Anyhow, the change should improve readablity. No functionality change intended. llvm-svn: 199214
2014-01-13Revert "ReMat: fix overly cavalier attitude to sub-register indices"Tim Northover1-4/+24
Very sorry, this was a premature patch that I still need to investigate and finish off (for some reason beyond me at the moment it doesn't actually fix the issue in all cases). This reverts commit r199091. llvm-svn: 199093
2014-01-13ReMat: fix overly cavalier attitude to sub-register indicesTim Northover1-24/+4
There are two attempted optimisations in reMaterializeTrivialDef, trying to avoid promoting the size of a register too much when rematerializing. Unfortunately, both appear to be flawed. First, we see if the original register would have worked, but this is inadequate. Consider: v1 = SOMETHING (v1 is QQ) v2:Q0 = COPY v1:Q1 (v1, v2 are QQ) ... uses of v2 In this case even though v2 *could* be used directly as the output of SOMETHING, this would set the wrong bits of the QQ register involved. The correct rematerialization must be: v2:Q0_Q1 = SOMETHING (v2 promoted to QQQ) ... uses of v2:Q1_Q2 For the second optimisation, if the correct remat is "v2:idx = SOMETHING" then we can't necessarily expect v2 itself to be valid for SOMETHING, but we do try to hunt for a class between v1 and v2 that works. Unfortunately, this is also wrong: v1 = SOMETHING (v1 is QQ) v2:Q0_Q1 = COPY v1 (v1 is QQ, v2 is QQQ) ... uses of v2 as a QQQ The canonical rematerialization here is "v2:Q0_Q1 = SOMETHING". However current logic would decide that v2 could be a QQ (no interest is taken in later uses). This patch, therefore, always accepts the widened register class without trying to be clever. Generally there is no penalty to this (e.g. in the common GR32 < GR64 case, expanding the width doesn't matter because it's not like you were going to do anything else with the high bits of a GR32 register). It can increase register pressure in cases like the ARM VFP regs though (multiple non-overlapping but equivalent subregisters). Hopefully this situation is rare enough that it won't matter. Unfortunately, no in-tree targets actually expose this as far as I can tell (there are so few isAsCheapAsAMove instructions for it to trigger on) so I've been unable to produce a test. It was exposed in our ARM64 SPEC tests though, and I will be adding a test there that we should be able to contribute soon(TM). llvm-svn: 199091
2013-10-10Print register in LiveInterval::print()Matthias Braun1-7/+8
llvm-svn: 192398
2013-10-10Represent RegUnit liveness with LiveRange instanceMatthias Braun1-2/+2
Previously LiveInterval has been used, but having a spill weight and register number is unnecessary for a register unit. llvm-svn: 192397
2013-10-10Work on LiveRange instead of LiveInterval where possibleMatthias Braun1-1/+1
Also change some pointer arguments to references at some places where 0-pointers are not allowed. llvm-svn: 192396
2013-10-10Pass LiveQueryResult by valueMatthias Braun1-6/+6
This makes the API a bit more natural to use and makes it easier to make LiveRanges implementation details private. llvm-svn: 192394
2013-10-10Rename LiveRange to LiveInterval::SegmentMatthias Braun1-34/+35
The Segment struct contains a single interval; multiple instances of this struct are used to construct a live range, but the struct is not a live range by itself. llvm-svn: 192392
2013-10-04Fix commentMatthias Braun1-1/+1
llvm-svn: 191966
2013-09-26Added temp flag -misched-bench for staging in default changes.Andrew Trick1-1/+1
llvm-svn: 191423
2013-09-22Provide basic type safety for array_pod_sort comparators.Benjamin Kramer1-3/+2
This makes using array_pod_sort significantly safer. The implementation relies on function pointer casting but that should be safe as we're dealing with void* here. llvm-svn: 191175
2013-09-06avoid unnecessary direct access to LiveInterval::rangesMatthias Braun1-6/+6
llvm-svn: 190170
2013-09-06remove unused argument from LiveRanges::join()Matthias Braun1-2/+1
llvm-svn: 190169
generated by cgit v1.1 at 2025-10-18 05:30:24 +0000