aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/LiveDebugVariables.h
AgeCommit message (Collapse)AuthorFilesLines
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-10-30Remove dead declarationMatt Arsenault1-7/+0
llvm-svn: 345555
2017-08-24[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use ↵Eugene Zelenko1-8/+5
warnings; other minor fixes (NFC). llvm-svn: 311703
2017-06-21Mark dump() methods as const. NFCSam Clegg1-1/+1
Add const qualifier to any dump() method where adding one was trivial. Differential Revision: https://reviews.llvm.org/D34481 llvm-svn: 305963
2016-04-18[NFC] Header cleanupMehdi Amini1-1/+1
Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
2015-11-07Erase unused FunctionDIs variables after r252219.Yaron Keren1-1/+0
llvm-svn: 252401
2015-07-01[CodeGen] Reduce visibility of implementation detailsBenjamin Kramer1-1/+1
NFC. llvm-svn: 241164
2015-04-29IR: Give 'DI' prefix to debug info metadataDuncan P. N. Exon Smith1-1/+1
Finish off PR23080 by renaming the debug info IR constructs from `MD*` to `DI*`. The last of the `DIDescriptor` classes were deleted in r235356, and the last of the related typedefs removed in r235413, so this has all baked for about a week. Note: If you have out-of-tree code (like a frontend), I recommend that you get everything compiling and tests passing with the *previous* commit before updating to this one. It'll be easier to keep track of what code is using the `DIDescriptor` hierarchy and what you've already updated, and I think you're extremely unlikely to insert bugs. YMMV of course. Back to *this* commit: I did this using the rename-md-di-nodes.sh upgrade script I've attached to PR23080 (both code and testcases) and filtered through clang-format-diff.py. I edited the tests for test/Assembler/invalid-generic-debug-node-*.ll by hand since the columns were off-by-three. It should work on your out-of-tree testcases (and code, if you've followed the advice in the previous paragraph). Some of the tests are in badly named files now (e.g., test/Assembler/invalid-mdcompositetype-missing-tag.ll should be 'dicompositetype'); I'll come back and move the files in a follow-up commit. llvm-svn: 236120
2015-04-17DebugInfo: Remove DIDescriptor from the DebugInfo APIDuncan P. N. Exon Smith1-1/+2
Stop using `DIDescriptor` and its subclasses in the `DebugInfoFinder` API, as well as the rest of the API hanging around in `DebugInfo.h`. llvm-svn: 235240
2015-04-11Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko1-1/+1
The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
2015-01-14[cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth1-1/+1
utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
2014-08-13Canonicalize header guards into a common format.Benjamin Kramer1-3/+3
Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
2014-07-25Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie1-0/+3
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-3/+0
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-0/+3
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-3/+0
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-0/+3
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-03-07[C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper1-3/+3
class. llvm-svn: 203220
2013-09-11Revert "Give internal classes hidden visibility."Benjamin Kramer1-1/+1
It works with clang, but GCC has different rules so we can't make all of those hidden. This reverts commit r190534. llvm-svn: 190536
2013-09-11Give internal classes hidden visibility.Benjamin Kramer1-1/+1
Worth 100k on a linux/x86_64 Release+Asserts clang. llvm-svn: 190534
2013-08-14Track new virtual registers by register number.Mark Lacey1-1/+3
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-02-13Clean up LDV, no functionality change.Manman Ren1-4/+0
Remove dead functions: renameRegister Move private member variables from LDV to Impl Remove ssp/uwtable from testing case llvm-svn: 175072
2013-02-13Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.Manman Ren1-0/+4
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
2011-05-06Update LiveDebugVariables after live range splitting.Jakob Stoklund Olesen1-0/+7
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
2010-12-03Emit DBG_VALUE instructions from LiveDebugVariables.Jakob Stoklund Olesen1-1/+4
llvm-svn: 120842
2010-12-02Update LiveDebugVariables during coalescing.Jakob Stoklund Olesen1-0/+3
llvm-svn: 120720
2010-12-02Implement the first half of LiveDebugVariables.Jakob Stoklund Olesen1-2/+2
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
2010-11-30Stub out a new LiveDebugVariables pass.Jakob Stoklund Olesen1-0/+57
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