summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DebugLocEntry.h
Commit message (Collapse)AuthorAgeFilesLines
* Move the complex address expression out of DIVariable and into an extraAdrian Prantl2014-10-011-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-30/+16
| | | | | | "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-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix some cases were ArrayRefs were being passed by reference. Also remove ↵Craig Topper2014-08-271-1/+1
| | | | | | 'const' from some other ArrayRef uses since its implicitly const already. llvm-svn: 216524
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | 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
* DebugLocEntry: Restore the comparison predicate from before theAdrian Prantl2014-08-121-1/+4
| | | | | | | | | refactoring in 215384. This way it can unique multiple entries describing the same piece even if they don't have the exact same location. (The same piece may get merged in and be added from OpenRanges). There ought to be a more elegant solution for this, though. llvm-svn: 215418
* Add a couple of convenience accessors to DebugLocEntry::Value to furtherAdrian Prantl2014-08-111-5/+5
| | | | | | simplify common usage patterns. llvm-svn: 215407
* Make these DebugLocEntry::Value comparison operators friend functionsAdrian Prantl2014-08-111-24/+34
| | | | | | as suggested by dblaikie in a comment on r215384. llvm-svn: 215403
* Debug info: Remove an obsolete constructor from DebugLocEntry.Adrian Prantl2014-08-111-2/+2
| | | | llvm-svn: 215387
* Debug info: Modify DebugLocEntry::addValue to take multiple values so itAdrian Prantl2014-08-111-6/+6
| | | | | | only has to sort/unique values once per batch. llvm-svn: 215386
* Debug Info: Move the sorting and uniqueing of pieces from emitLocPieces()Adrian Prantl2014-08-111-1/+17
| | | | | | | 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-8/+13
| | | | | | | | | | | | 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: Move the reference to the CU from the location list entry to the ↵David Blaikie2014-08-051-9/+3
| | | | | | | | | | 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
* Debug info: Infrastructure to support debug locations for fragmentedAdrian Prantl2014-08-011-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [C++] Use 'nullptr'.Craig Topper2014-04-281-1/+1
| | | | llvm-svn: 207394
* Debug Info: Prepare DebugLocEntry to handle more than a single value perAdrian Prantl2014-04-271-69/+69
| | | | | | | | | | entry. This is in preparation for generic DW_OP_piece support. No functional change so far. http://reviews.llvm.org/D3373 rdar://problem/15928306 llvm-svn: 207368
* Debug info: Store the DIVariable in DebugLocEntry also for constants,Adrian Prantl2014-04-111-6/+6
| | | | | | | | so DwarfDebug::emitDebugLocEntry can emit them with the correct signedness. rdar://problem/15928306 llvm-svn: 206042
* clarify commentAdrian Prantl2014-04-021-1/+2
| | | | llvm-svn: 205429
* Add a doxygen comment to DebugLocEntry::Merge.Adrian Prantl2014-04-011-0/+3
| | | | llvm-svn: 205374
* DebugLocEntry: Actually merge the loc entry when returning true.David Blaikie2014-04-011-1/+5
| | | | | | | | | | Seems we didn't have any test coverage for merging... awesome. So I added some - but hit an llvm-objdump bug while I was there. I'm choosing not to shave that yak right now. Code review feedback/bug catch by Adrian Prantl in r205360. llvm-svn: 205373
* Fix accidental fallthrough in DebugLocEntry::hasSameValueOrLocationDavid Blaikie2014-04-011-5/+10
| | | | | | | | | | No test case (this would invoke UB by examining uninitialized members, etc, at best - and this code is apparently untested anyway - I'm about to fix that) Code review feedback from Adrian Prantl on r205360. llvm-svn: 205367
* Remove unused function DebugLocEntry::isEmptyDavid Blaikie2014-04-011-3/+0
| | | | llvm-svn: 205365
* Refactor out the comparison of the location/value in a DebugLocEntryDavid Blaikie2014-04-011-18/+19
| | | | llvm-svn: 205364
* DebugInfo: Split DebugLocEntry into its own file.David Blaikie2014-04-011-0/+112
It seems big enough that it deserves its own file - but it is header only, so there's no need for another cpp file, etc. llvm-svn: 205360
OpenPOWER on IntegriCloud