summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Handle NewReg==OldReg in renameRegister().Jakob Stoklund Olesen2012-05-151-1/+2
| | | | | | | This can happen when widening a virtual register to a super-register class. llvm-svn: 156867
* Tabs.Eric Christopher2012-03-151-3/+3
| | | | llvm-svn: 152842
* Typo.Eric Christopher2012-03-151-1/+1
| | | | llvm-svn: 152841
* Add bundle aware API for querying instruction properties and switch the codeEvan Cheng2011-12-071-2/+2
| | | | | | | | | | | | | | generator to it. For non-bundle instructions, these behave exactly the same as the MC layer API. For properties like mayLoad / mayStore, look into the bundle and if any of the bundled instructions has the property it would return true. For properties like isPredicable, only return true if *all* of the bundled instructions have the property. For properties like canFoldAsLoad, isCompare, conservatively return false for bundles. llvm-svn: 146026
* Rename SlotIndexes to match how they are used.Jakob Stoklund Olesen2011-11-131-4/+4
| | | | | | | | | | | | | | | | | | | | The old naming scheme (load/use/def/store) can be traced back to an old linear scan article, but the names don't match how slots are actually used. The load and store slots are not needed after the deferred spill code insertion framework was deleted. The use and def slots don't make any sense because we are using half-open intervals as is customary in C code, but the names suggest closed intervals. In reality, these slots were used to distinguish early-clobber defs from normal defs. The new naming scheme also has 4 slots, but the names match how the slots are really used. This is a purely mechanical renaming, but some of the code makes a lot more sense now. llvm-svn: 144503
* Stop tracking spill slot uses in VirtRegMap.Jakob Stoklund Olesen2011-11-131-2/+1
| | | | | | | Nobody cared, StackSlotColoring scans the instructions to find used stack slots. llvm-svn: 144485
* Namespacify.Benjamin Kramer2011-09-161-0/+2
| | | | llvm-svn: 139892
* Use a cache to maintain list of machine basic blocks for a given UserValue.Devang Patel2011-09-131-10/+33
| | | | llvm-svn: 139616
* While extending definition range of a debug variable, consult lexical scopes ↵Devang Patel2011-08-101-10/+22
| | | | | | also. There is no point extending debug variable out side its lexical block. This provides 6x compile time speedup in some cases. llvm-svn: 137250
* Print variable's inline location in debug output.Devang Patel2011-08-091-2/+5
| | | | llvm-svn: 137096
* Increment counter inside insertDebugValue().Devang Patel2011-08-041-2/+1
| | | | llvm-svn: 136915
* Add counter.Devang Patel2011-08-041-1/+4
| | | | llvm-svn: 136901
* Correctly handle multiple DBG_VALUE instructions at the same SlotIndex.Jakob Stoklund Olesen2011-08-031-0/+3
| | | | | | | | | | | | It is possible to have multiple DBG_VALUEs for the same variable: 32L TEST32rr %vreg0<kill>, %vreg0, %EFLAGS<imp-def>; GR32:%vreg0 DBG_VALUE 2, 0, !"i" DBG_VALUE %noreg, %0, !"i" When that happens, keep the last one instead of the first. llvm-svn: 136842
* Typo.Devang Patel2011-07-061-1/+1
| | | | llvm-svn: 134559
* Remove an assertion to fix PR9872.Jakob Stoklund Olesen2011-05-081-0/+4
| | | | | | | | | | | | | | | | | | | | It can happen that a live debug variable is the last use of a sub-register, and the register allocator will pick a larger register class for the virtual register. If the allocated register doesn't support the sub-register index, just use %noreg for the debug variables instead of asserting. In PR9872, a debug variable ends up in the sub_8bit_hi part of a GR32_ABCD register. The register is split and one part is inflated to GR32 and assigned %ESI because there are no more normal uses of sub_8bit_hi. Since %ESI doesn't have that sub-register, substPhysReg asserted. Now it will simply insert a %noreg instead, and the debug variable will be marked unavailable in that range. We don't currently have a way of saying: !"value" is in bits 8-15 of %ESI, I don't know if DWARF even supports that. llvm-svn: 131073
* Iterate backwards over debug locations when splitting them so they can be ↵Jakob Stoklund Olesen2011-05-061-1/+4
| | | | | | | | safely erased. This should unbreak dragonegg-i386-linux and build-self-4-mingw32. llvm-svn: 131007
* Update LiveDebugVariables after live range splitting.Jakob Stoklund Olesen2011-05-061-1/+146
| | | | | | | | | | | | After a virtual register is split, update any debug user variables that resided in the old register. This ensures that the LiveDebugVariables are still correct after register allocation. This may create DBG_VALUE instructions that place a user variable in a register in parts of the function and in a stack slot in other parts. DwarfDebug currently doesn't support that. llvm-svn: 130998
* Use TargetMachine hooks to properly print debug variable locations.Jakob Stoklund Olesen2011-05-061-6/+7
| | | | llvm-svn: 130997
* Fix a ton of comment typos found by codespell. Patch byChris Lattner2011-04-151-1/+1
| | | | | | Luis Felipe Strano Moraes! llvm-svn: 129558
* Reapply r128045 and r128051 with fixes.Jakob Stoklund Olesen2011-03-221-17/+7
| | | | | | | | | | | | | | | | This will extend the ranges of debug info variables in registers until they are clobbered. Fix 1: Don't mistake DBG_VALUE instructions referring to incoming arguments on the stack with DBG_VALUE instructions referring to variables in the frame pointer. This fixes the gdb test-suite failure. Fix 2: Don't trace through copies to physical registers setting up call arguments. These registers are call clobbered, and the source register is more likely to be a callee-saved register that can be extended through the call instruction. llvm-svn: 128114
* Revert r128045 and r128051, debug info enhancements.Andrew Trick2011-03-221-0/+17
| | | | | | Temporarily reverting these to see if we can get llvm-objdump to link. Hopefully this is not the problem. llvm-svn: 128097
* Dont emit 'DBG_VALUE %noreg, ...' to terminate user variable ranges.Jakob Stoklund Olesen2011-03-221-17/+0
| | | | | | | | | | These ranges get completely jumbled by the post-ra scheduler, and it is not really reasonable to expect it to make sense of them. Instead, teach DwarfDebug to notice when user variables in registers are clobbered, and terminate the ranges there. llvm-svn: 128045
* Extend live debug values down the dominator tree by following copies.Jakob Stoklund Olesen2011-03-181-24/+136
| | | | | | | | | | | | | | | | | The llvm.dbg.value intrinsic refers to SSA values, not virtual registers, so we should be able to extend the range of a value by tracking that value through register copies. This greatly improves the debug value tracking for function arguments that for some reason are copied to a second virtual register at the end of the entry block. We only extend the debug value range where its register is killed. All original llvm.dbg.value locations are still respected. Copies from physical registers are ignored. That should not be a problem since the entry block already adds DBG_VALUE instructions for the virtual registers holding the function arguments. llvm-svn: 127912
* DebugLoc associated with a machine instruction is used to emit location ↵Devang Patel2011-02-041-20/+29
| | | | | | entries. DebugLoc associated with a DBG_VALUE is used to identify lexical scope of the variable. After register allocation, while inserting DBG_VALUE remember original debug location for the first instruction and reuse it, otherwise dwarf writer may be mislead in identifying the variable's scope. llvm-svn: 124845
* Better terminator avoidance.Jakob Stoklund Olesen2011-01-131-9/+3
| | | | | | | This approach also works when the terminator doesn't have a slot index. (Which can happen??) llvm-svn: 123413
* Temporary workaround for an i386 crash in LiveDebugVariables.Jakob Stoklund Olesen2011-01-131-1/+2
| | | | llvm-svn: 123400
* Try again enabling LiveDebugVariables.Jakob Stoklund Olesen2011-01-121-1/+1
| | | | llvm-svn: 123342
* Don't emit a DBG_VALUE for a spill slot that the rewriter decided not to use ↵Jakob Stoklund Olesen2011-01-121-1/+2
| | | | | | after all. llvm-svn: 123339
* Fix braino in dominator tree walk.Jakob Stoklund Olesen2011-01-121-1/+1
| | | | llvm-svn: 123338
* Sometimes, old virtual registers can linger on DBG_VALUE instructions.Jakob Stoklund Olesen2011-01-121-1/+2
| | | | | | Make sure we don't crash in that case, but simply turn them into %noreg instead. llvm-svn: 123335
* The world is not ready for LiveDebugVariables yet.Jakob Stoklund Olesen2011-01-111-1/+1
| | | | llvm-svn: 123290
* Enable LiveDebugVariables by default.Jakob Stoklund Olesen2011-01-111-1/+1
| | | | llvm-svn: 123282
* Don't insert DBG_VALUE instructions after the first terminator.Jakob Stoklund Olesen2011-01-111-0/+7
| | | | | | | | For one, MachineBasicBlock::getFirstTerminator() doesn't understand what is happening, and it also makes sense to have all control flow run through the DBG_VALUE. llvm-svn: 123277
* Simplify a bunch of isVirtualRegister() and isPhysicalRegister() logic.Jakob Stoklund Olesen2011-01-101-1/+1
| | | | | | | | These functions not longer assert when passed 0, but simply return false instead. No functional change intended. llvm-svn: 123155
* Simplify LiveDebugVariables by storing MachineOperand copies locations insteadJakob Stoklund Olesen2011-01-091-169/+48
| | | | | | | | | | | | | | of using a Location class with the same information. When making a copy of a MachineOperand that was already stored in a MachineInstr, it is necessary to clear the parent pointer on the copy. Otherwise the register use-def lists become inconsistent. Add MachineOperand::clearParent() to do that. An alternative would be a custom MachineOperand copy constructor that cleared ParentMI. I didn't want to do that because of the performance impact. llvm-svn: 123109
* Replace TargetRegisterInfo::printReg with a PrintReg class that also works ↵Jakob Stoklund Olesen2011-01-091-6/+1
| | | | | | | | | | without a TRI instance. Print virtual registers numbered from 0 instead of the arbitrary FirstVirtualRegister. The first virtual register is printed as %vreg0. TRI::NoRegister is printed as %noreg. llvm-svn: 123107
* Speculatively revert r123032.Devang Patel2011-01-071-0/+6
| | | | llvm-svn: 123039
* Appropriately truncate debug info range in dwarf output.Devang Patel2011-01-071-6/+0
| | | | | | Enable live debug variables pass. llvm-svn: 123032
* Rename virtRegMap to avoid confusion with the VirtRegMap that it isn't.Jakob Stoklund Olesen2010-12-031-5/+5
| | | | llvm-svn: 120846
* Coalesce debug locations when possible, causing less DBG_VALUE instructions toJakob Stoklund Olesen2010-12-031-2/+34
| | | | | | be emitted. llvm-svn: 120845
* Emit DBG_VALUE instructions from LiveDebugVariables.Jakob Stoklund Olesen2010-12-031-1/+181
| | | | llvm-svn: 120842
* Also update virtRegMap when renaming virtual registers.Jakob Stoklund Olesen2010-12-031-1/+11
| | | | llvm-svn: 120841
* Update LiveDebugVariables during coalescing.Jakob Stoklund Olesen2010-12-021-0/+49
| | | | llvm-svn: 120720
* Implement the first half of LiveDebugVariables.Jakob Stoklund Olesen2010-12-021-2/+505
| | | | | | | | | | | | | | | | | | | Scan the MachineFunction for DBG_VALUE instructions, and replace them with a data structure similar to LiveIntervals. The live range of a DBG_VALUE is determined by propagating it down the dominator tree until a new DBG_VALUE is found. When a DBG_VALUE lives in a register, its live range is confined to the live range of the register's value. LiveDebugVariables runs before coalescing, so DBG_VALUEs are not artificially extended when registers are joined. The missing half will recreate DBG_VALUE instructions from the intervals when register allocation is complete. The pass is disabled by default. It can be enabled with the temporary command line option -live-debug-variables. llvm-svn: 120636
* Stub out a new LiveDebugVariables pass.Jakob Stoklund Olesen2010-11-301-0/+50
This analysis is going to run immediately after LiveIntervals. It will stay alive during register allocation and keep track of user variables mentioned in DBG_VALUE instructions. When the register allocator is moving values between registers and the stack, it is very hard to keep track of DBG_VALUE instructions. We usually get it wrong. This analysis maintains a data structure that makes it easy to update DBG_VALUE instructions. llvm-svn: 120385
OpenPOWER on IntegriCloud