summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/RegisterCoalescer.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* RegisterCoalescer: rewrite eliminateUndefCopy().Matthias Braun2014-12-191-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
* RegisterCoalescer: Fix stripCopies() picking up main range instead of ↵Matthias Braun2014-12-171-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
* RegisterCoalescer: Sprinkle some const modifiers.Matthias Braun2014-12-171-11/+12
| | | | llvm-svn: 224409
* LiveInterval: Use range based for loops for subregister ranges.Matthias Braun2014-12-111-75/+61
| | | | llvm-svn: 223991
* LiveInterval: Use more range based for loops for value numbers and segments.Matthias Braun2014-12-101-10/+9
| | | | llvm-svn: 223978
* RegisterCoalescer: Preserve subregister liveranges.Matthias Braun2014-12-101-121/+559
| | | | llvm-svn: 223888
* LiveIntervalAnalysis: Add subregister aware variants pruneValue().Matthias Braun2014-12-101-2/+2
| | | | llvm-svn: 223886
* Simplify implementation and testcase of r223401 based on feedback from dblaikie.Adrian Prantl2014-12-041-4/+2
| | | | llvm-svn: 223405
* Debug info: If the RegisterCoalescer::reMaterializeTrivialDef() isAdrian Prantl2014-12-041-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
* RegisterCoalescer: Improve debug messagesMatthias Braun2014-11-191-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
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-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
* Move register class name strings to a single array in MCRegisterInfo to ↵Craig Topper2014-11-171-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
* delete function names from commentsSanjay Patel2014-10-091-32/+30
| | | | llvm-svn: 219444
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+2
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Add TargetInstrInfo interface isAsCheapAsAMove.Jiangning Liu2014-07-291-1/+1
| | | | llvm-svn: 214158
* [RegisterCoalescer] Moving the RegisterCoalescer subtarget hook onto the ↵Chris Bieneman2014-07-161-2/+1
| | | | | | TargetRegisterInfo instead of the TargetSubtargetInfo. llvm-svn: 213188
* [RegisterCoalescer] Add new subtarget hook allowing targets to opt-out of ↵Chris Bieneman2014-07-151-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
* Convert more loops to range-based equivalentsAlexey Samsonov2014-04-301-3/+2
| | | | llvm-svn: 207714
* [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-10/+11
| | | | | | instead of comparing to nullptr. llvm-svn: 206142
* [Register Coalescer] Fix wrong live-range information with rematerialization.Quentin Colombet2014-04-111-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
* Switch a number of loops in lib/CodeGen over to range-based for-loops, now thatOwen Anderson2014-03-171-9/+5
| | | | | | the MachineRegisterInfo iterators are compatible with it. llvm-svn: 204075
* Remove some dead assignements found by scan-buildArnaud A. de Grandmaison2014-03-151-1/+0
| | | | llvm-svn: 204013
* Phase 2 of the great MachineRegisterInfo cleanup. This time, we're changingOwen Anderson2014-03-131-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
* Phase 1 of refactoring the MachineRegisterInfo iterators to make them suitableOwen Anderson2014-03-131-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
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-071-5/+5
| | | | | | class. llvm-svn: 203220
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-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
* [C++11] Replace llvm::tie with std::tie.Benjamin Kramer2014-03-021-1/+1
| | | | | | The old implementation is no longer needed in C++11. llvm-svn: 202644
* [C++11] Replace llvm::next and llvm::prior with std::next and std::prev.Benjamin Kramer2014-03-021-2/+2
| | | | | | Remove the old functions. llvm-svn: 202636
* ReMat: fix overly cavalier attitude to sub-register indicesTim Northover2014-01-161-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
* Fix valgrind warning for gcc builds.Patrik Hagglund2014-01-141-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
* Revert "ReMat: fix overly cavalier attitude to sub-register indices"Tim Northover2014-01-131-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
* ReMat: fix overly cavalier attitude to sub-register indicesTim Northover2014-01-131-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
* Print register in LiveInterval::print()Matthias Braun2013-10-101-7/+8
| | | | llvm-svn: 192398
* Represent RegUnit liveness with LiveRange instanceMatthias Braun2013-10-101-2/+2
| | | | | | | Previously LiveInterval has been used, but having a spill weight and register number is unnecessary for a register unit. llvm-svn: 192397
* Work on LiveRange instead of LiveInterval where possibleMatthias Braun2013-10-101-1/+1
| | | | | | | Also change some pointer arguments to references at some places where 0-pointers are not allowed. llvm-svn: 192396
* Pass LiveQueryResult by valueMatthias Braun2013-10-101-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
* Rename LiveRange to LiveInterval::SegmentMatthias Braun2013-10-101-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
* Fix commentMatthias Braun2013-10-041-1/+1
| | | | llvm-svn: 191966
* Added temp flag -misched-bench for staging in default changes.Andrew Trick2013-09-261-1/+1
| | | | llvm-svn: 191423
* Provide basic type safety for array_pod_sort comparators.Benjamin Kramer2013-09-221-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
* avoid unnecessary direct access to LiveInterval::rangesMatthias Braun2013-09-061-6/+6
| | | | llvm-svn: 190170
* remove unused argument from LiveRanges::join()Matthias Braun2013-09-061-2/+1
| | | | llvm-svn: 190169
* remove pointless assertMatthias Braun2013-09-061-2/+0
| | | | | | The if above it ensures the property anyway. llvm-svn: 190168
* fix commentMatthias Braun2013-09-061-1/+1
| | | | | | There's no 'B3' in the example. llvm-svn: 190167
* Track new virtual registers by register number.Mark Lacey2013-08-141-1/+1
| | | | | | | | | | Track new virtual registers by register number, rather than by the live interval created for them. This is the first step in separating the creation of new virtual registers and new live intervals. Eventually live intervals will be created and populated on demand after the virtual registers have been created and used in instructions. llvm-svn: 188434
* Use modern API to avoid exposing LiveInterval internals.Jakob Stoklund Olesen2013-07-051-5/+3
| | | | | | No functional change intended. llvm-svn: 185733
OpenPOWER on IntegriCloud