summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Push the CURangeList down into the skeleton CU (where available) rather than ↵David Blaikie2014-11-031-1/+1
| | | | | | | | | | | | | | | | | the full CU So that it may be shared between skeleton/full compile unit, for CU ranges and other ranges to be added for fission+gmlt. (at some point we might want some kind of object shared between the skeleton and full compile units for all those things we only want one of in that scope, rather than having the full unit always look through to the skeleton... - alternatively, we might be able to have the skeleton pointer (or another, separate pointer) point to the skeleton or to the unit itself in non-fission, so we don't have to special case its absence) llvm-svn: 221186
* Add DwarfCompileUnit::BaseAddress to track the base address used by relative ↵David Blaikie2014-11-031-6/+3
| | | | | | | | | | | | | | addressing in debug_ranges and debug_loc This is one of a few steps to generalize range handling to include the CU range (thus the CU's range list will be moved into the range list list, losing track of the base address in the process), which means generalizing ranges from both the skeleton and full unit under fission. And... then I can used that generalized support for ranges in fission+gmlt where there'll be a bunch more ranges in the skeleton. llvm-svn: 221182
* Sink DwarfUnit::CURanges into DwarfCompileUnitDavid Blaikie2014-11-031-1/+1
| | | | llvm-svn: 221161
* FormattingDavid Blaikie2014-11-021-1/+1
| | | | llvm-svn: 221095
* Add DwarfUnit::isDwoUnit and use it to generalize string creationDavid Blaikie2014-11-021-5/+6
| | | | | | | | | | | | | | | | | | | Currently we only need to emit skeleton strings into the CU header and we do this by explicitly calling "addLocalString". With gmlt-in-fission, we'll be emitting a bunch of other strings from other codepaths where it's not statically known that these strings will be local or not. Introduce a virtual function to indicate whether this unit is a DWO unit or not (I'm not sure if we have a good term for this, the opposite/alternative to 'skeleton' unit) and use that to generalize the string emission logic so that strings can be correctly emitted in both the skeleton and dwo unit when in split dwarf mode. And to demonstrate that this works, switch the existing special callers of addLocalString in the skeleton builder to addString - and they still work. Yay. llvm-svn: 221094
* DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into ↵David Blaikie2014-11-021-3/+5
| | | | | | DwarfCompileUnit llvm-svn: 221083
* Drop DwarfCompileUnit::getLocalLabel* in favor of just mapping through the ↵David Blaikie2014-11-021-1/+5
| | | | | | | | | skeleton explicitly. Confusing to do this two different ways - I'm not too wedded to either one, but here goes. llvm-svn: 221076
* Remove DwarfUnit::LabelEnd in favor of computing the length of the section ↵David Blaikie2014-11-011-1/+1
| | | | | | | | | | directly This was a compile-unit specific label (unused in type units) and seems unnecessary anyway when we can more easily directly compute the size of the compile unit. llvm-svn: 221067
* Sink DwarfUnit::SectionSym into DwarfCompileUnit as it's only needed/used there.David Blaikie2014-11-011-2/+1
| | | | llvm-svn: 221062
* And... fix the build some more.David Blaikie2014-11-011-1/+1
| | | | llvm-svn: 221036
* Just iterate the DwarfCompileUnits rather than trying to filter them out of ↵David Blaikie2014-11-011-49/+46
| | | | | | the list of all units. llvm-svn: 221034
* Add '*' to auto variable that is a pointer, as per the coding conventions.David Blaikie2014-11-011-1/+1
| | | | llvm-svn: 221033
* Add DwarfCompileUnit::getSkeleton that returns DwarfCompileUnit* to avoid ↵David Blaikie2014-11-011-3/+2
| | | | | | having to cast from DwarfUnit* on every call. llvm-svn: 221031
* Sink some of DwarfDebug::collectDeadVariables down into DwarfCompileUnit.David Blaikie2014-10-311-20/+1
| | | | llvm-svn: 221010
* Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE into ↵David Blaikie2014-10-311-5/+1
| | | | | | DwarfCompileUnit llvm-svn: 221005
* Minimize the scope of some variables, NFC.David Blaikie2014-10-281-2/+2
| | | | llvm-svn: 220759
* DebugInfo: Sink DwarfDebug::ScopeVariables down into DwarfFileDavid Blaikie2014-10-241-2/+2
| | | | | | | | (part of refactoring to allow subprogram emission in both the skeleton and main units to enable -gmlt-like data to be included in the skeleton for live inlined backtracing purposes) llvm-svn: 220578
* Remove DwarfDebug::FirstCU as it has no useDavid Blaikie2014-10-241-11/+5
| | | | | | | It was only being used as a flag to identify the lack of debug info from within endModule - use the section labels for that instead. llvm-svn: 220575
* DebugInfo: Remove DwarfDebug::addScopeVariable now that it's just a trivial ↵David Blaikie2014-10-241-8/+4
| | | | | | wrapper llvm-svn: 220542
* DebugInfo: Remove DwarfDebug::CurrentFnArguments since we have to handle ↵David Blaikie2014-10-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | argument ordering of other arguments (abstract arguments) in the same way and already have code for that too. While refactoring this code I was confused by both the name I had introduced (addNonArgumentVariable... but it has all this logic to handle argument numbering and keep things in order?) and by the redundancy. Seems when I fixed the misordered inlined argument handling, I didn't realize it was mostly redundant with the argument ordering code (which I may've also written, I'm not sure). So let's just rely on the more general case. The only oddity in output this produces is that it means when we emit all the variables for the current function, we don't track when we've finished the argument variables and are about to start the local variables and insert DW_AT_unspecified_parameters (for varargs functions) there. Instead it ends up after the local variables, scopes, etc. But this isn't invalid and doesn't cause DWARF consumers problems that I know of... so we'll just go with that because it makes the code nice & simple. (though, let's see what the buildbots have to say about this - *crosses fingers*) There will be some cleanup commits to follow to remove the now trivial wrappers, etc. llvm-svn: 220527
* DebugInfo: Sink DwarfDebug::addNonArgumentScopeVariable into DwarfFile.David Blaikie2014-10-231-34/+2
| | | | llvm-svn: 220520
* [DebugInfo] Sink DwarfDebug::addCurrentFnArgument down into DwarfFile.David Blaikie2014-10-231-24/+1
| | | | | | | | Variable handling will be sunk into DwarfFile so that abstract variables and the like can be shared across multiple CUs (to handle cross-CU inlining, for example). llvm-svn: 220453
* [DebugInfo] Add DwarfDebug& to DwarfFile.David Blaikie2014-10-231-4/+5
| | | | | | | | Use the DwarfDebug in one function that previously took it as a parameter, and lay the foundation for use this for other operations coming soon. llvm-svn: 220452
* [DebugInfo] Remove LexicalScopes::isCurrentFunctionScope and CSE a use of ↵David Blaikie2014-10-231-12/+16
| | | | | | | | | | LexicalScopes::getCurrentFunctionScope Now that we're sure the only root (non-abstract) scope is the current function scope, there's no need for isCurrentFunctionScope, the property can be tested directly instead. llvm-svn: 220451
* Revert some parts of r196288 that were confusing and untested.David Blaikie2014-10-141-8/+2
| | | | | | | If we figure out why they should be here, let's add some testing of some kind so we can better demonstrate why it's needed. llvm-svn: 219694
* Add an assertion about the integrity of the iterator.Adrian Prantl2014-10-131-0/+5
| | | | | | | | | Broken parent scope pointers in inlined DIVariables can cause ensureAbstractVariableIsCreated to insert new abstract scopes, thus invalidating the iterator in this loop and leading to hard-to-debug crashes. Useful when manually reducing IR for testcases. llvm-svn: 219628
* Simplify a few uses of DwarfDebug::SPMapDavid Blaikie2014-10-101-21/+3
| | | | llvm-svn: 219510
* Sink the per-CU part of DwarfDebug::finishSubprogramDefinitions into ↵David Blaikie2014-10-101-15/+1
| | | | | | DwarfCompileUnit. llvm-svn: 219477
* Sink most of DwarfDebug::constructAbstractSubprogramScopeDIE down into ↵David Blaikie2014-10-101-23/+3
| | | | | | DwarfCompileUnit. llvm-svn: 219476
* Avoid unnecessary map lookup/insertion.David Blaikie2014-10-101-2/+2
| | | | llvm-svn: 219466
* Remove unused parameterDavid Blaikie2014-10-091-4/+3
| | | | llvm-svn: 219440
* Sink DwarfDebug::createAndAddScopeChildren down into DwarfCompileUnit.David Blaikie2014-10-091-14/+1
| | | | llvm-svn: 219437
* 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
OpenPOWER on IntegriCloud