Temporarily reverting these to see if we can get llvm-objdump to link. Hopefully this is not the problem.

llvm-svn: 128097

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

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 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

This approach also works when the terminator doesn't have a slot index. (Which
can happen??)

llvm-svn: 123413

llvm-svn: 123400

llvm-svn: 123342

llvm-svn: 123339

llvm-svn: 123338

Make sure we don't crash in that case, but simply turn them into %noreg instead.

llvm-svn: 123335

llvm-svn: 123290

llvm-svn: 123282

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

These functions not longer assert when passed 0, but simply return false instead.

No functional change intended.

llvm-svn: 123155

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

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

llvm-svn: 123039

Enable live debug variables pass.

llvm-svn: 123032

llvm-svn: 120846

be emitted.

llvm-svn: 120845

llvm-svn: 120842

llvm-svn: 120841

llvm-svn: 120720

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

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