aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
AgeCommit message (Collapse)AuthorFilesLines
2013-11-20Remove capability for polymorphic destruction from LexicalScopeEric Christopher1-1/+0
and LexicalScopes, we're not using it. llvm-svn: 195182
2013-11-20Grammar.Eric Christopher1-1/+1
llvm-svn: 195181
2013-10-10Represent RegUnit liveness with LiveRange instanceMatthias Braun1-9/+9
Previously LiveInterval has been used, but having a spill weight and register number is unnecessary for a register unit. llvm-svn: 192397
2013-10-10Rename LiveRange to LiveInterval::SegmentMatthias Braun1-4/+4
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-09-16Debug info: Fix PR16736 and rdar://problem/14990587.Adrian Prantl1-1/+2
A DBG_VALUE is register-indirect iff the first operand is a register _and_ the second operand is an immediate. llvm-svn: 190821
2013-08-14Track new virtual registers by register number.Mark Lacey1-11/+15
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
2013-07-09Reapply an improved version of r180816/180817.Adrian Prantl1-10/+19
Change the informal convention of DBG_VALUE machine instructions so that we can express a register-indirect address with an offset of 0. The old convention was that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain register values the combination reg, reg is used. MachineInstrBuilder::BuildMI knows how to build the new DBG_VALUES. rdar://problem/13658587 llvm-svn: 185966
2013-06-16Debug Info: Simplify Frame Index handling in DBG_VALUE Machine InstructionsDavid Blaikie1-12/+0
Rather than using the full power of target-specific addressing modes in DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This reduces the complexity of debug info handling down to two representations of values (reg+offset and frame index+offset) rather than three or four. Ideally we could ensure that frame indicies had been eliminated by the time we reached an assembly or dwarf generation, but I haven't spent the time to figure out where the FIs are leaking through into that & whether there's a good place to convert them. Some FI+offset=>reg+offset conversion is done (see PrologEpilogInserter, for example) which is necessary for some SelectionDAG assumptions about registers, I believe, but it might be possible to make this a more thorough conversion & ensure there are no remaining FIs no matter how instruction selection is performed. llvm-svn: 184066
2013-04-30Temporarily revert "Change the informal convention of DBG_VALUE so that we ↵Adrian Prantl1-22/+11
can express a" because it breaks some buildbots. This reverts commit 180816. llvm-svn: 180819
2013-04-30Change the informal convention of DBG_VALUE so that we can express aAdrian Prantl1-11/+22
register-indirect address with an offset of 0. It used to be that a DBG_VALUE is a register-indirect value if the offset (operand 1) is nonzero. The new convention is that a DBG_VALUE is register-indirect if the first operand is a register and the second operand is an immediate. For plain registers use the combination reg, reg. rdar://problem/13658587 llvm-svn: 180816
2013-02-13Clean up LDV, no functionality change.Manman Ren1-60/+19
Remove dead functions: renameRegister Move private member variables from LDV to Impl Remove ssp/uwtable from testing case llvm-svn: 175072
2013-02-13Fix comment.Eric Christopher1-2/+2
llvm-svn: 175024
2013-02-13Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.Manman Ren1-4/+12
RegisterCoalescer used to depend on LiveDebugVariable. LDV removes DBG_VALUEs without emitting them at the end. We fix this by removing LDV from RegisterCoalescer. Also add an assertion to make sure we call emitDebugValues if DBG_VALUEs are removed at runOnMachineFunction. rdar://problem/13183203 Reviewed by Andy & Jakob llvm-svn: 175023
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-3/+3
into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth1-4/+4
Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-11-28Make the LiveRegMatrix analysis available to targets.Jakob Stoklund Olesen1-1/+1
No functional change, just moved header files. Targets can inject custom passes between register allocation and rewriting. This makes it possible to tweak the register allocation before rewriting, using the full global interference checking available from LiveRegMatrix. llvm-svn: 168806
2012-08-22Tidy up a few more uses of MF.getFunction()->getName().David Blaikie1-2/+1
Based on CR feedback from r162301 and Craig Topper's refactoring in r162347 here are a few other places that could use the same API (& in one instance drop a Function.h dependency). llvm-svn: 162367
2012-06-28Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp andBill Wendling1-1/+1
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h. The reasoning is because the DebugInfo module is simply an interface to the debug info MDNodes and has nothing to do with analysis. llvm-svn: 159312
2012-06-22Don't depend on live ranges being present.Jakob Stoklund Olesen1-3/+8
DBG_VALUE instructions could be referring to non-existing virtual registers. llvm-svn: 159020
2012-06-22Use regunit liveness to guide LiveDebugVariables.Jakob Stoklund Olesen1-5/+18
This should produce the same results as using physreg liveness directly. llvm-svn: 159009
2012-05-15Handle NewReg==OldReg in renameRegister().Jakob Stoklund Olesen1-1/+2
This can happen when widening a virtual register to a super-register class. llvm-svn: 156867
2012-03-15Tabs.Eric Christopher1-3/+3
llvm-svn: 152842
2012-03-15Typo.Eric Christopher1-1/+1
llvm-svn: 152841
2011-12-07Add bundle aware API for querying instruction properties and switch the codeEvan Cheng1-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
2011-11-13Rename SlotIndexes to match how they are used.Jakob Stoklund Olesen1-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
2011-11-13Stop tracking spill slot uses in VirtRegMap.Jakob Stoklund Olesen1-2/+1
Nobody cared, StackSlotColoring scans the instructions to find used stack slots. llvm-svn: 144485
2011-09-16Namespacify.Benjamin Kramer1-0/+2
llvm-svn: 139892
2011-09-13Use a cache to maintain list of machine basic blocks for a given UserValue.Devang Patel1-10/+33
llvm-svn: 139616
2011-08-10While extending definition range of a debug variable, consult lexical scopes ↵Devang Patel1-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
2011-08-09Print variable's inline location in debug output.Devang Patel1-2/+5
llvm-svn: 137096
2011-08-04Increment counter inside insertDebugValue().Devang Patel1-2/+1
llvm-svn: 136915
2011-08-04Add counter.Devang Patel1-1/+4
llvm-svn: 136901
2011-08-03Correctly handle multiple DBG_VALUE instructions at the same SlotIndex.Jakob Stoklund Olesen1-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
2011-07-06Typo.Devang Patel1-1/+1
llvm-svn: 134559
2011-05-08Remove an assertion to fix PR9872.Jakob Stoklund Olesen1-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
2011-05-06Iterate backwards over debug locations when splitting them so they can be ↵Jakob Stoklund Olesen1-1/+4
safely erased. This should unbreak dragonegg-i386-linux and build-self-4-mingw32. llvm-svn: 131007
2011-05-06Update LiveDebugVariables after live range splitting.Jakob Stoklund Olesen1-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
2011-05-06Use TargetMachine hooks to properly print debug variable locations.Jakob Stoklund Olesen1-6/+7
llvm-svn: 130997
2011-04-15Fix a ton of comment typos found by codespell. Patch byChris Lattner1-1/+1
Luis Felipe Strano Moraes! llvm-svn: 129558
2011-03-22Reapply r128045 and r128051 with fixes.Jakob Stoklund Olesen1-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
2011-03-22Revert r128045 and r128051, debug info enhancements.Andrew Trick1-0/+17
Temporarily reverting these to see if we can get llvm-objdump to link. Hopefully this is not the problem. llvm-svn: 128097
2011-03-22Dont emit 'DBG_VALUE %noreg, ...' to terminate user variable ranges.Jakob Stoklund Olesen1-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
2011-03-18Extend live debug values down the dominator tree by following copies.Jakob Stoklund Olesen1-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
2011-02-04DebugLoc associated with a machine instruction is used to emit location ↵Devang Patel1-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
2011-01-13Better terminator avoidance.Jakob Stoklund Olesen1-9/+3
This approach also works when the terminator doesn't have a slot index. (Which can happen??) llvm-svn: 123413
2011-01-13Temporary workaround for an i386 crash in LiveDebugVariables.Jakob Stoklund Olesen1-1/+2
llvm-svn: 123400
2011-01-12Try again enabling LiveDebugVariables.Jakob Stoklund Olesen1-1/+1
llvm-svn: 123342
2011-01-12Don't emit a DBG_VALUE for a spill slot that the rewriter decided not to use ↵Jakob Stoklund Olesen1-1/+2
after all. llvm-svn: 123339
2011-01-12Fix braino in dominator tree walk.Jakob Stoklund Olesen1-1/+1
llvm-svn: 123338
2011-01-12Sometimes, old virtual registers can linger on DBG_VALUE instructions.Jakob Stoklund Olesen1-1/+2
Make sure we don't crash in that case, but simply turn them into %noreg instead. llvm-svn: 123335
generated by cgit v1.1 at 2025-10-27 02:11:07 +0000