summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Debug info: Allow aggregate types to be described by constants.Adrian Prantl2015-01-071-2/+5
| | | | llvm-svn: 225378
* Debug Info: In symmetry to DW_TAG_pointer_type, do not emit the byte sizeAdrian Prantl2014-12-241-1/+2
| | | | | | | of a DW_TAG_ptr_to_member_type. This restores the behavior from before r224780-r224781. llvm-svn: 224799
* Explain why LLVM is emitting a DW_AT_containing_type inside of a class.Adrian Prantl2014-12-191-0/+2
| | | | llvm-svn: 224555
* PR21875: codegen for non-type template parameters of nullptr_t typeDavid Blaikie2014-12-171-2/+5
| | | | llvm-svn: 224399
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* These two calls were grabbing the same register info. Unify them.Eric Christopher2014-12-051-3/+2
| | | | llvm-svn: 223502
* Cleanup: Calls to getDwarfRegNum() may actually fail, if there isAdrian Prantl2014-12-051-10/+16
| | | | | | | | | | | | | no DWARF register number mapping, or if the register was a virtual register that was never materialized. Previously, we would just emit a bogus location, after this patch we don't emit a location at all by doing an early exit. After my bugfix in r223401 today, this doesn't actually happen on any target that I tested this with, but it's still preferable to make the possibility of a failure explicit. llvm-svn: 223428
* Provide gmlt-like inline scope information in the skeleton CU to facilitate ↵David Blaikie2014-11-041-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | symbolication without needing the .dwo files Clang -gsplit-dwarf self-host -O0, binary increases by 0.0005%, -O2, binary increases by 25%. A large binary inside Google, split-dwarf, -O0, and other internal flags (GDB index, etc) increases by 1.8%, optimized build is 35%. The size impact may be somewhat greater in .o files (I haven't measured that much - since the linked executable -O0 numbers seemed low enough) due to relocations. These relocations could be removed if we taught the llvm-symbolizer to handle indexed addressing in the .o file (GDB can't cope with this just yet, but GDB won't be reading this info anyway). Also debug_ranges could be shared between .o and .dwo, though ideally debug_ranges would get a schema that could used index(+offset) addressing, and move to the .dwo file, then we'd be back to sharing addresses in the address pool again. But for now, these sizes seem small enough to go ahead with this. Verified that no other DW_TAGs are produced into the .o file other than subprograms and inlined_subroutines. llvm-svn: 221306
* Move cross-unit DIE caching to the DwarfFile level, so it doesn't interfere ↵David Blaikie2014-11-041-2/+2
| | | | | | with fission-gmlt data and produce skeleton<>full unit cross referencing. llvm-svn: 221305
* Add DwarfUnit::isDwoUnit and use it to generalize string creationDavid Blaikie2014-11-021-2/+11
| | | | | | | | | | | | | | | | | | | 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
* Remove the last mention of LineTablesOnly from DwarfUnit, sinking it into ↵David Blaikie2014-11-021-2/+3
| | | | | | | | | | | | | | DwarfCompileUnit This is a useful distinction/invariant/delination to make because LineTablesOnly mode is never relevant to type units, so it's clear that we're not doing weird line-tables-only-with-types by making this API choice. It also lays the foundations nicely for adding gmlt-like data to fission skeleton CUs while limiting the effects to CUs and not TUs. llvm-svn: 221093
* Sink DwarfUnit::applySubprogramAttributesToDefinition into DwarfCompileUnitDavid Blaikie2014-11-021-7/+0
| | | | llvm-svn: 221092
* Sink DwarfUnit::addExpr into DwarfCompileUnitDavid Blaikie2014-11-021-7/+0
| | | | llvm-svn: 221090
* Sink DwarfUnit::applyVariableAttributes into DwarfCompileUnitDavid Blaikie2014-11-021-11/+0
| | | | llvm-svn: 221088
* Sink DwarfUnit::addLocationList down into DwarfCompileUnitDavid Blaikie2014-11-021-10/+0
| | | | llvm-svn: 221087
* Sink DwarfUnit::addComplexAddress down into DwarfCompileUnitDavid Blaikie2014-11-021-59/+0
| | | | llvm-svn: 221086
* Push DwarfUnit::addAddress down into DwarfCompileUnitDavid Blaikie2014-11-021-19/+0
| | | | llvm-svn: 221085
* Sink DwarfUnit::addVariableAddress into DwarfCompileUnit since type units ↵David Blaikie2014-11-021-13/+0
| | | | | | don't have variables llvm-svn: 221084
* DebugInfo: Sink accelerator table lists down (GlobalNames/Types) into ↵David Blaikie2014-11-021-16/+0
| | | | | | DwarfCompileUnit llvm-svn: 221083
* Add DwarfUnit::addGlobalType to match DwarfUnit::addGlobalNameDavid Blaikie2014-11-021-5/+11
| | | | | | | | | (these will shortly become virtual, with a null implementation in DwarfUnit (since type units don't have accelerator tables in the current schema) and the current implementation down in DwarfCompileUnit, moving the actual maps there too) llvm-svn: 221082
* DebugInfo: Refactor index type DIE initialization by rolling it into the ↵David Blaikie2014-11-021-9/+12
| | | | | | accessor llvm-svn: 221080
* Sink DwarfUnit::LabelBegin down into DwarfCompileUnit since that's the only ↵David Blaikie2014-11-021-2/+0
| | | | | | place it's needed. llvm-svn: 221075
* Sink dwarf unit length emission down into DwarfUnit::emitHeaderDavid Blaikie2014-11-011-0/+4
| | | | | | | | This allows the CU label to be emitted only for compile units, as they're the only ones that need it (so they can be referenced from pubnames) llvm-svn: 221072
* Remove DwarfUnit::LabelEnd in favor of computing the length of the section ↵David Blaikie2014-11-011-2/+0
| | | | | | | | | | 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-13/+9
| | | | llvm-svn: 221062
* Sink DwarfUnit::Skeleton down into DwarfCompileUnitDavid Blaikie2014-11-011-2/+1
| | | | | | | | | Type units no longer have skeletons and it's misleading to be able to query for a type unit's skeleton (it might incorrectly lead one to conclude that if a unit doesn't have a skeleton it's not in a .dwo file... ). llvm-svn: 221055
* Remove some unnecessary casts.David Blaikie2014-10-261-2/+2
| | | | llvm-svn: 220658
* Sink DwarfUnit::constructImportedEntityDIE into DwarfCompileUnit.Frederic Riss2014-10-241-28/+0
| | | | | | | | | | So that it has access to getOrCreateGlobalVariableDIE. If we ever support decsribing using directive in C++ classes (thus requiring support in type units), it will certainly use another mechanism anyway. Differential Revision: http://reviews.llvm.org/D5975 llvm-svn: 220594
* Move DwarfUnit::constructVariableDIE down to DwarfCompileUnit, since it's ↵David Blaikie2014-10-091-63/+0
| | | | | | only needed there. llvm-svn: 219418
* Sink DwarfUnit::addSectionDelta into DwarfCompileUnit, the only place it's ↵David Blaikie2014-10-081-10/+0
| | | | | | needed. llvm-svn: 219364
* Sink and coalesce DwarfDebug.cpp::addSectionLabel and ↵David Blaikie2014-10-081-10/+0
| | | | | | DwarfUnit::addSectionLabel down into DwarfCompileUnit::addSectionLabel llvm-svn: 219351
* DebugInfo: Sink constructImportedEntityDIE down into DwarfUnit from DwarfDebug.David Blaikie2014-10-061-0/+28
| | | | | | | | 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
* Move DwarfCompileUnit from DwarfUnit.h to its own header (DwarfCompileUnit.h)David Blaikie2014-10-041-264/+2
| | | | | | | | | | | | 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
* Revert "Revert "DI: Fold constant arguments into a single MDString""Duncan P. N. Exon Smith2014-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r218918, effectively reapplying r218914 after fixing an Ocaml bindings test and an Asan crash. The root cause of the latter was a tightened-up check in `DILexicalBlock::Verify()`, so I'll file a PR to investigate who requires the loose check (and why). Original commit message follows. -- This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 219010
* Revert "DI: Fold constant arguments into a single MDString"Duncan P. N. Exon Smith2014-10-021-1/+1
| | | | | | This reverts commit r218914 while I investigate some bots. llvm-svn: 218918
* DI: Fold constant arguments into a single MDStringDuncan P. N. Exon Smith2014-10-021-1/+1
| | | | | | | | | | | | | This patch addresses the first stage of PR17891 by folding constant arguments together into a single MDString. Integers are stringified and a `\0` character is used as a separator. Part of PR17891. Note: I've attached my testcases upgrade scripts to the PR. If I've just broken your out-of-tree testcases, they might help. llvm-svn: 218914
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-14/+10
| | | | | | "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-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement DW_TAG_subrange_type with DW_AT_count rather than DW_AT_upper_boundDavid Blaikie2014-10-011-6/+3
| | | | | | | | | | | | | | | This allows proper disambiguation of unbounded arrays and arrays of zero bound ("struct foo { int x[]; };" and "struct foo { int x[0]; }"). GCC instead produces an upper bound of -1 in the latter situation, but count seems tidier. This way lower_bound is provided if it's not the language default and count is provided if the count is known, otherwise it's omitted. Simple. If someone wants to look at rdar://problem/12566646 and see if this change is acceptable to that bug/fix, that might be helpful (see the empty-and-one-elem-array.ll test case which cites that radar). llvm-svn: 218726
* Omit DW_TAG_subprograms for subprograms without inlined subroutines when ↵David Blaikie2014-09-191-16/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Describe the -gmlt optimization committed in the previous revision.David Blaikie2014-09-191-0/+1
| | | | llvm-svn: 218099
* Omit all the extra static attributes on subprograms in -gmltDavid Blaikie2014-09-191-0/+3
| | | | | | | | This omission will be done in a fancier manner once we're dealing with "put gmlt in the skeleton CUs under fission" - it'll have to be conditional on the kind of CU we're emitting into (skeleton or gmlt). llvm-svn: 218098
* Revert part of r218041.Frederic Riss2014-09-181-0/+3
| | | | | | | | The patch moved some logic around in an attempt to generate potentially more DW_AT_declaration attributes. The patch was flawed though and it stopped generating the attribute in some cases. llvm-svn: 218060
* Always emit DW_AT_declaration attribute when the variable isn't a definition.Frederic Riss2014-09-181-3/+3
| | | | | | | | | | | | | | | Summary: This doesn't show up today as we don't emit decalration only variables. This will be tested when the followup patches implementing import of forward declared entities lands in clang. Reviewers: echristo, dblaikie, aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5382 llvm-svn: 218041
* DebugInfo: Add comment describing the need to disable address pool usage in ↵David Blaikie2014-09-151-0/+5
| | | | | | | | skeleton units. Post commit review from Eric Christopher. llvm-svn: 217842
* Remove the unused string section symbol parameter from DwarfFile::emitStringsDavid Blaikie2014-09-111-4/+2
| | | | | | | | | | | | | | | | | | | 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-2/+4
| | | | | | | | | 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-6/+3
| | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud