aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.cpp
AgeCommit message (Collapse)AuthorFilesLines
2014-10-24Added reset of LexicalScope in LiveDebugVariables reset function.Marcello Maggioni1-0/+1
llvm-svn: 220545
2014-10-01Move the complex address expression out of DIVariable and into an extraAdrian Prantl1-20/+28
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! Note: I accidentally committed a bogus older version of this patch previously. llvm-svn: 218787
2014-10-01Revert r218778 while investigating buldbot breakage.Adrian Prantl1-28/+20
"Move the complex address expression out of DIVariable and into an extra" llvm-svn: 218782
2014-10-01Move the complex address expression out of DIVariable and into an extraAdrian Prantl1-20/+28
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics. Previously, DIVariable was a variable-length field that has an optional reference to a Metadata array consisting of a variable number of complex address expressions. In the case of OpPiece expressions this is wasting a lot of storage in IR, because when an aggregate type is, e.g., SROA'd into all of its n individual members, the IR will contain n copies of the DIVariable, all alike, only differing in the complex address reference at the end. By making the complex address into an extra argument of the dbg.value/dbg.declare intrinsics, all of the pieces can reference the same variable and the complex address expressions can be uniqued across the CU, too. Down the road, this will allow us to move other flags, such as "indirection" out of the DIVariable, too. The new intrinsics look like this: declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr) declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr) This patch adds a new LLVM-local tag to DIExpressions, so we can detect and pretty-print DIExpression metadata nodes. What this patch doesn't do: This patch does not touch the "Indirect" field in DIVariable; but moving that into the expression would be a natural next step. http://reviews.llvm.org/D4919 rdar://problem/17994491 Thanks to dblaikie and dexonsmith for reviewing this patch! llvm-svn: 218778
2014-08-07test commit: remove trailing whitespace.Frederic Riss1-2/+2
llvm-svn: 215138
2014-08-05Have MachineFunction cache a pointer to the subtarget to make lookupsEric Christopher1-3/+2
shorter/easier and have the DAG use that to do the same lookup. This can be used in the future for TargetMachine based caching lookups from the MachineFunction easily. Update the MIPS subtarget switching machinery to update this pointer at the same time it runs. llvm-svn: 214838
2014-08-04Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher1-2/+4
information and update all callers. No functional change. llvm-svn: 214781
2014-07-25Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie1-3/+26
functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. This was then reverted again in r213581 as it caused PR20367. The root cause of this was the early exit in LiveDebugVariables meant that spurious DBG_VALUE intrinsics that referenced dead variables were not removed, causing an assertion/crash later on. The fix is to have LiveDebugVariables strip all DBG_VALUE intrinsics in functions without debug info as they're not needed anyway. Test case added to cover this situation (that occurs when a debug-having function is inlined into a nodebug function) in test/DebugInfo/X86/nodebug_with_debug_loc.ll Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 213952
2014-07-21Revert "Recommit r212203: Don't try to construct debug LexicalScopes ↵David Blaikie1-12/+3
hierarchy for functions that do not have top level debug information." This reverts commit r212649 while I investigate/reduce/etc PR20367. llvm-svn: 213581
2014-07-09Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie1-3/+12
functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212649
2014-07-03Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for ↵Eric Christopher1-12/+3
functions that do not have top level debug information." as it appears to be breaking some LTO constructs. This reverts commit r212203. llvm-svn: 212298
2014-07-02Don't try to construct debug LexicalScopes hierarchy for functions that do ↵David Blaikie1-3/+12
not have top level debug information. If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212203
2014-04-25This reapplies r207235 with an additional bugfixes caught by the msanAdrian Prantl1-3/+3
buildbot - do not insert debug intrinsics before phi nodes. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207269
2014-04-25Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl1-3/+3
check for" This reverts commit 207235 to investigate msan buildbot breakage. llvm-svn: 207250
2014-04-25This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl1-3/+3
AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207235
2014-04-25Revert "This reapplies r207130 with an additional testcase+and a missing ↵Adrian Prantl1-3/+3
check for" Typo in testcase. llvm-svn: 207166
2014-04-25This reapplies r207130 with an additional testcase+and a missing check forAdrian Prantl1-3/+3
AllocaInst that was missing in one location. Debug info for optimized code: Support variables that are on the stack and described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine.ll testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207165
2014-04-25Revert "Debug info for optimized code: Support variables that are on the ↵Adrian Prantl1-3/+3
stack and" This reverts commit 207130 for buildbot breakage. llvm-svn: 207162
2014-04-24Debug info for optimized code: Support variables that are on the stack andAdrian Prantl1-3/+3
described by DBG_VALUEs during their lifetime. Previously, when a variable was at a FrameIndex for any part of its lifetime, this would shadow all other DBG_VALUEs and only a single fbreg location would be emitted, which in fact is only valid for a small range and not the entire lexical scope of the variable. The included dbg-value-const-byref testcase demonstrates this. This patch fixes this by Local - emitting dbg.value intrinsics for allocas that are passed by reference - dropping all dbg.declares (they are now fully lowered to dbg.values) SelectionDAG - renamed constructors for SDDbgValue for better readability. - fix UserValue::match() to handle indirect values correctly - not inserting an MMI table entries for dbg.values that describe allocas. - lowering dbg.values that describe allocas into *indirect* DBG_VALUEs. CodeGenPrepare - leaving dbg.values for an alloca were they are (see comment) Other - regenerated/updated instcombine-intrinsics testcase and included source rdar://problem/16679879 http://reviews.llvm.org/D3374 llvm-svn: 207130
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-21Use unique_ptr to handle ownership of UserValues in LiveDebugVariablesImplDavid Blaikie1-4/+6
llvm-svn: 206785
2014-04-14[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-9/+9
instead of comparing to nullptr. llvm-svn: 206142
2014-03-17Switch a number of loops in lib/CodeGen over to range-based for-loops, now thatOwen Anderson1-5/+3
the MachineRegisterInfo iterators are compatible with it. llvm-svn: 204075
2014-03-13Phase 2 of the great MachineRegisterInfo cleanup. This time, we're changingOwen Anderson1-2/+2
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-06[Layering] Move DebugInfo.h into the IR library where its implementationChandler Carruth1-1/+1
already lives. llvm-svn: 203046
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
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
generated by cgit v1.1 at 2025-10-19 13:44:19 +0000