summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
* DebugInfo: Elide lexical scopes which only contain other (inline or lexical) ↵David Blaikie2014-08-311-12/+27
| | | | | | | | | | | | | | | | | | | | | scopes. DW_TAG_lexical_scopes inform debuggers about the instruction range for which a given variable (or imported declaration/module/etc) is valid. If the scope doesn't itself contain any such entities, it's a waste of space and should be omitted. We were correctly doing this for entirely empty leaves, but not for intermediate nodes. Reduces total (not just debug sections) .o file size for a bootstrap -gmlt LLVM by 22% and bootstrap -gmlt clang executable by 13%. The wins for a full -g build will be less as a % (and in absolute terms), but should still be substantial - with some of that win being fewer relocations, thus more substantiall reducing link times than fewer bytes alone would have. llvm-svn: 216861
* DebugInfo: Move argument creation up into the caller that's unambiguously ↵David Blaikie2014-08-311-25/+33
| | | | | | handling the subprogram scope (replacing a conditional with an assertion in the process) llvm-svn: 216845
* Delay adding imported entity DIEs to the lexical scope, streamlining the ↵David Blaikie2014-08-311-5/+5
| | | | | | | | | | check for "this scope has nothing in it" This makes the emptiness of the scope with regards to variables and nested scopes is the same as with regards to imported entities. Just check if we had nothing at all before we build the node. llvm-svn: 216840
* Modify DwarfDebug::constructImportedEntityDIE to return rather than insert ↵David Blaikie2014-08-311-11/+5
| | | | | | | | into the scope Another step towards improving lexical_scope handling llvm-svn: 216839
* Refactor constructImportedEntityDIE(DwarfUnit, DIImportedEntity) to return a ↵David Blaikie2014-08-311-9/+13
| | | | | | | | | | | DIE rather than inserting it into a specified context. First of many steps to improve lexical scope construction (to omit trivial lexical scopes - those without any direct variables). To that end it's easier not to create imported entities directly into the lexical scope node, but to build them, then add them if necessary. llvm-svn: 216838
* Simplify expression using container's front() rather than begin()->David Blaikie2014-08-311-3/+1
| | | | llvm-svn: 216833
* Revert accidentally committed patches r216787-r216789David Blaikie2014-08-291-26/+9
| | | | | | | | | | Rushed when I realized I hadn't committed the FreeDeleter for a clang change I'd committed, and didn't check that I had things lying around in my client. Apologies for the noise. llvm-svn: 216792
* Omit dwarf::DW_AT_frame_base under -gmltDavid Blaikie2014-08-291-3/+6
| | | | llvm-svn: 216788
* StuffDavid Blaikie2014-08-291-6/+20
| | | | llvm-svn: 216787
* Use DwarfDebug::attachLowHighPC for the compilation unit DIE.Frederic Riss2014-08-291-4/+1
| | | | llvm-svn: 216719
* Constify MCSymbol* parameters to DwarfDebug::attachLowHighPC.Frederic Riss2014-08-281-1/+1
| | | | llvm-svn: 216681
* Remove type unit skeletons. GDB no longer needs them & this saves a heap of ↵David Blaikie2014-08-271-22/+1
| | | | | | space. llvm-svn: 216521
* Use DILexicalBlockFile, rather than DILexicalBlock, to track discriminator ↵David Blaikie2014-08-211-2/+2
| | | | | | | | | | | | | | | changes to ensure discriminator changes don't introduce new DWARF DW_TAG_lexical_blocks. Somewhat unnoticed in the original implementation of discriminators, but it could cause instructions to end up in new, small, DW_TAG_lexical_blocks due to the use of DILexicalBlock to track discriminator changes. Instead, use DILexicalBlockFile which we already use to track file changes without introducing new scopes, so it works well to track discriminator changes in the same way. llvm-svn: 216239
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* Remove a condition that can never be true, as wittnessed by the assertAdrian Prantl2014-08-121-3/+2
| | | | | | above. llvm-svn: 215477
* Revert "Partially revert r214761 that asserted that all concrete debug info ↵David Blaikie2014-08-121-3/+1
| | | | | | | | | | | variables had DIEs, due to a failure on Darwin." I believe this was addressed by r215157 and r215227, so let's have another go at the bots, etc. This reverts commit r214880. llvm-svn: 215412
* Add a couple of convenience accessors to DebugLocEntry::Value to furtherAdrian Prantl2014-08-111-8/+7
| | | | | | simplify common usage patterns. llvm-svn: 215407
* Debug info: Modify DebugLocEntry::addValue to take multiple values so itAdrian Prantl2014-08-111-2/+3
| | | | | | only has to sort/unique values once per batch. llvm-svn: 215386
* Debug info: Further simplify the implementation of buildLocationList byAdrian Prantl2014-08-111-6/+6
| | | | | | getting rid of the redundant DIVariable in the OpenRanges pair. llvm-svn: 215385
* Debug Info: Move the sorting and uniqueing of pieces from emitLocPieces()Adrian Prantl2014-08-111-17/+5
| | | | | | | into buildLocationList(). By keeping the list of Values sorted, DebugLocEntry::Merge can also merge multi-piece entries. llvm-svn: 215384
* Debug info: Refactor DebugLocEntry's Merge function to makeAdrian Prantl2014-08-111-6/+24
| | | | | | | | | | | | buildLocationLists easier to read. The previous implementation conflated the merging of individual pieces and the merging of entire DebugLocEntries. By splitting this functionality into two separate functions the intention of the code should be clearer. llvm-svn: 215383
* DebugInfo: Recommit (reverted in r215217, originally committed in r215157) ↵David Blaikie2014-08-081-0/+1
| | | | | | | | | the assertion that no argument variable is overwritten by subsequent argument variables. This turned up a bug in clang where arguments were emitted with duplicate argument numbers (see r215227). llvm-svn: 215228
* DebugInfo: Remove assertion (added in r215157) that's firing on a blocksDavid Blaikie2014-08-081-1/+0
| | | | | | test in the test-suite while I investigate further. llvm-svn: 215217
* DebugInfo: Fix overwriting/loss of inlined arguments to recursively inlined ↵David Blaikie2014-08-071-4/+2
| | | | | | | | | | | | | | | | | | | | | functions. Due to an unnecessary special case, inlined arguments that happened to be from the same function as they were inlined into were misclassified as non-inline arguments and would overwrite the non-inlined arguments. Assert that we never overwrite a function's arguments, and stop misclassifying inlined arguments as non-inline arguments to fix this issue. Excuse the rather crappy test case - handcrafted IR might do better, or someone who understands better how to tickle the inliner to create a recursive inlining situation like this (though it may also be necessary to tickle the variable in a particular way to cause it to be recorded in the MMI side table and go down this particular path for location information). llvm-svn: 215157
* DebugInfo: Assert that any CU for which debug_loc lists are emitted, has at ↵David Blaikie2014-08-061-0/+1
| | | | | | | | | | | | | | | | least one range. This was coming in weird debug info that had variables (and hence debug_locs) but was in GMLT mode (because it was missing the 13th field of the compile_unit metadata) so no ranges were constructed. We should always have at least one range for any CU with a debug_loc in it - because the range should cover the debug_loc. The assertion just ensures that the "!= 1" range case inside the subsequent loop doesn't get entered for the case where there are no ranges at all, which should never reach here in the first place. llvm-svn: 214939
* DebugInfo: Move the reference to the CU from the location list entry to the ↵David Blaikie2014-08-051-7/+7
| | | | | | | | | | list itself, since it is constant across an entire list. This simplifies construction and usage while making the data structure smaller. It was a holdover from the days when we didn't have a separate DebugLocList and all we had was a flat list of DebugLocEntries. llvm-svn: 214933
* Partially revert r214761 that asserted that all concrete debug info ↵David Blaikie2014-08-051-1/+2
| | | | | | | | variables had DIEs, due to a failure on Darwin. I'll work on a reduction and fix after this. llvm-svn: 214880
* Remove the TargetMachine forwards for TargetSubtargetInfo basedEric Christopher2014-08-041-2/+4
| | | | | | information and update all callers. No functional change. llvm-svn: 214781
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-08-041-2/+1
| | | | | | | | | | | | | | instructions within a function, lead to the function itself." Originally reverted in r213432 with flakey failures on an ASan self-host build. After reduction it seems to be the same issue fixed in r213805 (ArgPromo + DebugInfo: Handle updating debug info over multiple applications of argument promotion) and r213952 (by having LiveDebugVariables strip dbg_value intrinsics in functions that are not described by debug info). Though I cannot explain why this failure was flakey... llvm-svn: 214761
* Attempt to increase the overall happiness of the MSCV-based buildbots.Adrian Prantl2014-08-011-1/+1
| | | | llvm-svn: 214588
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-011-38/+189
| | | | | | | | | | | | | | | | | | | | | | | | variables (for example, by-value struct arguments passed in registers, or large integer values split across several smaller registers). On the IR level, this adds a new type of complex address operation OpPiece to DIVariable that describes size and offset of a variable fragment. On the DWARF emitter level, all pieces describing the same variable are collected, sorted and emitted as DWARF expressions using the DW_OP_piece and DW_OP_bit_piece operators. http://reviews.llvm.org/D3373 rdar://problem/15928306 What this patch doesn't do / Future work: - This patch only adds the backend machinery to make this work, patches that change SROA and SelectionDAG's type legalizer to actually create such debug info will follow. (http://reviews.llvm.org/D2680) - Making the DIVariable complex expressions into an argument of dbg.value will reduce the memory footprint of the debug metadata. - The sorting/uniquing of pieces should be moved into DebugLocEntry, to facilitate the merging of multi-piece entries. llvm-svn: 214576
* Feedback on r214189, no functionality change.Manman Ren2014-07-291-1/+1
| | | | llvm-svn: 214240
* [Debug Info] remove DITrivialType and use null to represent unspecified param.Manman Ren2014-07-291-3/+5
| | | | | | | | | | | | Per feedback on r214111, we are going to use null to represent unspecified parameter. If the type array is {null}, it means a function that returns void; If the type array is {null, null}, it means a variadic function that returns void. In summary if we have more than one element in the type array and the last element is null, it is a variadic function. rdar://17628609 llvm-svn: 214189
* [Debug Info] unique MDNodes in the enum types of each compile unit.Manman Ren2014-07-281-2/+7
| | | | | | | | | The enum types array by design contains pointers to MDNodes rather than DIRefs. Unique them when handling the enum types in DwarfDebug. rdar://17628609 llvm-svn: 214139
* [Debug Info] add DISubroutineType and its creation takes DITypeArray. Manman Ren2014-07-281-2/+2
| | | | | | | | | | | DITypeArray is an array of DITypeRef, at its creation, we will create DITypeRef (i.e use the identifier if the type node has an identifier). This is the last patch to unique the type array of a subroutine type. rdar://17628609 llvm-svn: 214132
* [Debug Info] rename getTypeArray to getElements, setTypeArray to setArrays.Manman Ren2014-07-281-2/+2
| | | | | | | | | | | | | | | This is the second of a series of patches to handle type uniqueing of the type array for a subroutine type. For vector and array types, getElements returns the array of subranges, so it is a better name than getTypeArray. Even for class, struct and enum types, getElements returns the members, which can be subprograms. setArrays can set up to two arrays, the second is the templates. This commit should have no functionality change. llvm-svn: 214112
* Reapply "DebugInfo: Don't put fission type units in comdat sections."David Blaikie2014-07-251-12/+14
| | | | | | | | | | | | | | | | This recommits r208930, r208933, and r208975 (by reverting r209338) and reverts r209529 (the FIXME to readd this functionality once the tools were fixed) now that DWP has been fixed to cope with a single section for all fission type units. Original commit message: "Since type units in the dwo file are handled by a debug aware tool, they don't need to leverage the ELF comdat grouping to implement deduplication. Avoid creating all the .group sections for these as a space optimization." llvm-svn: 213956
* Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie2014-07-251-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Recommit r212203: Don't try to construct debug LexicalScopes ↵David Blaikie2014-07-211-16/+1
| | | | | | | | hierarchy for functions that do not have top level debug information." This reverts commit r212649 while I investigate/reduce/etc PR20367. llvm-svn: 213581
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵Eric Christopher2014-07-181-1/+2
| | | | | | | | | | instructions within a function, lead to the function itself."""" After a successful build it seems to have come back on a later build. This reverts commit r213391. llvm-svn: 213432
* DebugInfo: Assert that all abstract scopes are subprograms, rather than ↵David Blaikie2014-07-181-2/+1
| | | | | | | | conditionalizing. There's nothing else these should ever be... llvm-svn: 213417
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-181-2/+1
| | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself.""" Recommits 212776 which was reverted in r212793. This has been committed and recommitted a few times as I try to test it harder and find/fix more issues. The most recent revert was due to an asan bot failure which I can't seem to reproduce locally, though I believe I'm following all the steps the buildbot does. So I'm going to recommit this in the hopes of investigating the failure on the buildbot itself... apologies in advance for the bot noise. If anyone sees failures with this /please/ provide me with any reproductions, etc. llvm-svn: 213391
* CodeGen: add missing includeSaleem Abdulrasool2014-07-141-0/+1
| | | | | | | Found during windows unwinding work. This header is indirectly included through a chain leading through Support/Win64EH.h. Explicitly include the header. NFC. llvm-svn: 212955
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-111-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r212776. Nope, still seems to be failing on the sanitizer bots... but hey, not the msan self-host anymore, it's failing in asan now. I'll start looking there next. llvm-svn: 212793
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself." Committed in r212205 and reverted in r212226 due to msan self-hosting failure, I believe I've got that fixed by r212761 to Clang. Original commit message: "Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions." llvm-svn: 212776
* Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie2014-07-091-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for ↵Eric Christopher2014-07-031-9/+1
| | | | | | | | 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
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-021-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself." This reverts commit r212205. Reverting this again, still seeing crashes when building compiler-rt... Sorry for the continued noise, not sure why I'm failing to reproduce this locally. llvm-svn: 212226
OpenPOWER on IntegriCloud