Commit Graph

55 Commits

Author SHA1 Message Date
Adrian Prantl 7875142b5c Format the dwarfdump --statistics version as an integer instead of a string.
llvm-svn: 343864
2018-10-05 17:41:30 +00:00
Adrian Prantl 2e102480ac llvm-dwarfdump --statistics: Unique abstract origins across multiple CUs.
Instead of indexing local variables by DIE offset, use the variable
name + the path through the lexical block tree. This makes the lookup
key consistent across duplicate abstract origins in different CUs.

llvm-svn: 342776
2018-09-21 21:59:34 +00:00
Wolfgang Pieb 61d8c8d9b3 [DWARF] Improved error reporting for range lists.
Errors found processing the DW_AT_ranges attribute are propagated by lower level 
routines and reported by their callers.

Reviewer: JDevlieghere

Differential Revision: https://reviews.llvm.org/D48344

llvm-svn: 335188
2018-06-20 22:56:37 +00:00
Nicola Zaghen d34e60ca85 Rename DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
- Manual change to APInt
- Manually chage DOCS as regex doesn't match it.

In the transition period the DEBUG() macro is still present and aliased
to the LLVM_DEBUG() one.

Differential Revision: https://reviews.llvm.org/D43624

llvm-svn: 332240
2018-05-14 12:53:11 +00:00
Adrian Prantl 59f30b8874 llvm-dwarfdump: Add an option to collect debug info quality metrics.
At the last LLVM dev meeting we had a debug info for optimized code
BoF session. In that session I presented some graphs that showed how
the quality of the debug info produced by LLVM changed over the last
couple of years. This is a cleaned up version of the patch I used to
collect the this data. It is implemented as an extension of
llvm-dwarfdump, adding a new --statistics option. The intended
use-case is to automatically run this on the debug info produced by,
e.g., our bots, to identify eyebrow-raising changes or regressions
introduced by new transformations that we could act on.

In the current form, two kinds of data are being collected:

- The number of variables that have a debug location versus the number
  of variables in total (this takes into account inlined instances of
  the same function, so if a variable is completely missing form only
  one instance it will be found).

- The PC range covered by variable location descriptions versus the PC
  range of all variables' containing lexical scopes.

The output format is versioned and extensible, so I'm looking forward
to both bug fixes and ideas for other data that would be interesting
to track.

Differential Revision: https://reviews.llvm.org/D36627

llvm-svn: 315101
2017-10-06 20:24:34 +00:00