summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Sink DwarfDebug::constructSubprogramScopeDIE down into DwarfCompileUnitDavid Blaikie2014-10-091-43/+1
| | | | llvm-svn: 219436
* Sink DwarfDebug::createScopeChildrenDIE down into DwarfCompileUnit.David Blaikie2014-10-091-21/+3
| | | | llvm-svn: 219422
* Sink DwarfDebug.cpp::constructVariableDIE into DwarfCompileUnit.David Blaikie2014-10-091-12/+2
| | | | llvm-svn: 219419
* Sink DwarfDebug::constructLexicalScopeDIE into DwarfCompileUnitDavid Blaikie2014-10-091-17/+0
| | | | llvm-svn: 219414
* Sink DwarfDebug::constructInlinedScopeDIE into DwarfCompileUnitDavid Blaikie2014-10-091-31/+0
| | | | | | | | | | | This introduces access to the AbstractSPDies map from DwarfDebug so DwarfCompileUnit can access it. Eventually this'll sink down to DwarfFile, but it'll still be generically accessible - not much encapsulation to provide it. (constructInlinedScopeDIE could stay further up, in DwarfFile to avoid exposing this - but I don't think that's particularly better) llvm-svn: 219411
* Push DwarfDebug::attachRangesOrLowHighPC down into DwarfCompileUnitDavid Blaikie2014-10-091-12/+2
| | | | llvm-svn: 219372
* Sink DwarfDebug::addScopeRangeList down into DwarfCompileUnitDavid Blaikie2014-10-091-26/+1
| | | | | | | | | | | | | (& add a few accessors/make a couple of things public for this - it's a bit of a toss-up, but I think I prefer it this way, keeping some more of the meaty code down in DwarfCompileUnit - if only to make for smaller implementation files, etc) I think we could simplify range handling a bit if we removed the range lists from each unit and just put a single range list on DwarfDebug, similar to address pooling. llvm-svn: 219370
* Sink and coalesce DwarfDebug.cpp::addSectionLabel and ↵David Blaikie2014-10-081-20/+10
| | | | | | DwarfUnit::addSectionLabel down into DwarfCompileUnit::addSectionLabel llvm-svn: 219351
* DebugInfo: The rest of pushing DwarfDebug::constructScopeDIE down into ↵David Blaikie2014-10-081-68/+1
| | | | | | | | | DwarfCompileUnit Funnily enough, I copied it, but didn't actually remove the original in r219345. Let's do that. llvm-svn: 219346
* DebugInfo: Sink constructImportedEntityDIE down into DwarfUnit from DwarfDebug.David Blaikie2014-10-061-31/+2
| | | | | | | | It was just calling a bunch of DwarfUnit functions anyway, as can be seen by the simplification of removing "TheCU" from all the function calls in the implementation. llvm-svn: 219103
* Remove unused mapDavid Blaikie2014-10-051-2/+0
| | | | | | This became unnecessary/unused in r208636 llvm-svn: 219085
* Sink DwarfDebug::updateSubprogramScopeDIE into DwarfCompileUnitDavid Blaikie2014-10-041-27/+1
| | | | | | | | | | | | | This requires exposing some of the current function state from DwarfDebug. I hope there's not too much of that to expose as I go through all the functions, but it still seems nicer to expose singular data down to multiple consumers, than have consumers expose raw mapping data structures up to DwarfDebug for building subprograms. Part of a series of refactoring to allow subprograms in both the skeleton and dwo CUs under Fission. llvm-svn: 219060
* Sink DwarfDebug::attachLowHighPC into DwarfCompileUnitDavid Blaikie2014-10-041-18/+4
| | | | | | | One of many things to sink down into DwarfCompileUnit to allow handling of subprograms in both the skeleton and dwo CU under Fission. llvm-svn: 219058
* Move DwarfCompileUnit from DwarfUnit.h to its own header (DwarfCompileUnit.h)David Blaikie2014-10-041-1/+3
| | | | | | | | | | | | In preparation for sinking all the subprogram emission code down from DwarfDebug into DwarfCompileUnit, this will avoid bloating DwarfUnit.h/cpp greatly and make concerns a bit more clear/isolated. (sinking this handling down is part of the work to handle emitting minimal subprograms for -gmlt-like data into the skeleton CU under fission) llvm-svn: 219057
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-43/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r218778 while investigating buldbot breakage.Adrian Prantl2014-10-011-51/+43
| | | | | | "Move the complex address expression out of DIVariable and into an extra" llvm-svn: 218782
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-43/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Omit DW_AT_inline under -gmlt to save a little more space.David Blaikie2014-09-301-1/+2
| | | | llvm-svn: 218719
* DebugInfo: Sink the code emitting DW_AT_APPLE_omit_frame_ptr down to a more ↵David Blaikie2014-09-301-6/+4
| | | | | | | | | | | common spot. No functional change. Pre-emptive refactoring before I start pushing some of this subprogram creation down into DWARFCompileUnit so I can build different subprograms in the skeleton unit from the dwo unit for adding -gmlt-like data to the skeleton. llvm-svn: 218713
* Disable the -gmlt optimization implemented in r218129 under Darwin due to ↵David Blaikie2014-09-301-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | issues with dsymutil. r218129 omits DW_TAG_subprograms which have no inlined subroutines when emitting -gmlt data. This makes -gmlt very low cost for -O0 builds. Darwin's dsymutil reasonably considers a CU empty if it has no subprograms (which occurs with the above optimization in -O0 programs without any force_inline function calls) and drops the line table, CU, and everything in this situation, making backtraces impossible. Until dsymutil is modified to account for this, disable this optimization on Darwin to preserve the desired functionality. (see r218545, which should be reverted after this patch, for other discussion/details) Footnote: In the long term, it doesn't look like this scheme (of simplified debug info to describe inlining to enable backtracing) is tenable, it is far too size inefficient for optimized code (the DW_TAG_inlined_subprograms, even once compressed, are nearly twice as large as the line table itself (also compressed)) and we'll be considering things like Cary's two level line table proposal to encode all this information directly in the line table. llvm-svn: 218702
* Omit DW_TAG_subprograms for subprograms without inlined subroutines when ↵David Blaikie2014-09-191-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | producing -gmlt data To reduce the size of -gmlt data, skip the subprograms without any inlined subroutines. Since we've now got the ability to make these determinations in the backend (funnily enough - we added the flag so we wouldn't produce ranges under -gmlt, but with this change we use the flag, but go back to producing ranges under -gmlt). Instead, just produce CU ranges to inform the consumer which parts of the code are described by this CU's line table. Tools could inspect the line table directly to compute the range, but the CU ranges only seem to be about 0.5% of object/executable size, so I'm not too worried about teaching llvm-symbolizer that trick just yet - it's certainly a possible piece of future work. Update an llvm-symbolizer test just to demonstrate that this schema is acceptable there (if it wasn't, the compiler-rt tests would catch this, but good to have an in-llvm-tree test for llvm-symbolizer's behavior here) Building the clang binary with -gmlt with this patch reduces the total size of object files by 5.1% (5.56% without ranges) without compression and the executable by 4.37% (4.75% without ranges). llvm-svn: 218129
* Change DwarfCompileUnit::createGlobalVariable to getOrCreateGlobalVariable.Frederic Riss2014-09-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This will allow to request the creation of a forward delacred variable at is point of use (for imported declarations, this will be DwarfDebug::constructImportedEntityDIE) rather than having to put the forward decl in a retention list. Note that getOrCreateGlobalVariable returns the actual definition DIE when the routine creates a declaration and a definition DIE. If you agree this is the right behavior, then I'll have a followup patch that registers the definition in the DIE map instead of the declaration as it is today (this 'breaks' only one test, where we test that the imported entity is the declaration). I'm not sure what's best here, but it's easy enough for a consumer to follow the DW_AT_specification link to get to the declaration, whereas it takes more work to find the actual definition from a declaration DIE. Reviewers: echristo, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5381 llvm-svn: 218126
* Omit DW_AT_frame_base under -gmlt for sizeDavid Blaikie2014-09-191-3/+7
| | | | llvm-svn: 218100
* Remove the unused string section symbol parameter from DwarfFile::emitStringsDavid Blaikie2014-09-111-34/+20
| | | | | | | | | | | | | | | | | | | And since it /looked/ like the DwarfStrSectionSym was unused, I tried removing it - but then it turned out that DwarfStringPool was reconstructing the same label (and expecting it to have already been emitted) and uses that. So I kept it around, but wanted to pass it in to users - since it seemed a bit silly for DwarfStringPool to have it passed in and returned but itself have no use for it. The only two users don't handle strings in both .dwo and .o files so they only ever need the one symbol - no need to keep it (and have an unused symbol) in the DwarfStringPool used for fission/.dwo. Refactor a bunch of accelerator table usage to remove duplication so I didn't have to touch 4-5 callers. llvm-svn: 217628
* Sink PrevCU updating into DwarfUnit::addRange to ensure consistencyDavid Blaikie2014-09-091-1/+0
| | | | | | | | | So that the two operations in DwarfDebug couldn't get separated (because I accidentally separated them in some work in progress), put them together. While we're here, move DwarfUnit::addRange to DwarfCompileUnit, since it's not relevant to type units. llvm-svn: 217468
* Remove DwarfDebug::PrevSection, PrevCU is sufficient for handling address ↵David Blaikie2014-09-091-2/+0
| | | | | | | | | | | | | range holes. PrevSection/PrevCU are used to detect holes in the address range of a CU to ensure the DW_AT_ranges does not include those holes. When we see a function with no debug info, though it may be in the same range as the prior and subsequent functions, there should be a gap in the CU's ranges. By setting PrevCU to null in that case, the range would not be extended to cover the gap. llvm-svn: 217466
* 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
OpenPOWER on IntegriCloud