[PATCH] D70548: [llvm-dwarfdump][Statistics] Unify coverage statistic computation

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 22 12:25:38 PST 2019


dblaikie added a comment.

In D70548#1756279 <https://reviews.llvm.org/D70548#1756279>, @djtodoro wrote:

> @krisb Thanks for working on this!
>
> Let me summarize this quickly.
>
> This will remove mixing between calculation against enclosing and adjusted scope. We have concluded the adjustment heuristics are confusing and wrong in many cases, so we are giving up on that. The alternative is to generate the `DW_AT_start_scope` attribute, that represents exactly the adjusted scope, and having that we will be able to calculate the debug location statistics for the pieces of code where the variable is alive.
>
> WDYT how "easy" will be to implement the `DW_AT_start_scope` attribute? I know that it might not be used anywhere else, but I think that having location statistics against variable's life will be very useful thing.


See my reply from D69027 <https://reviews.llvm.org/D69027> - though thinking more closely, I'm not sure start_scope would really answer the question as it seems like it has many of the same issues as the adjusted scope we're removing - it assumes the code is laid out in order. Any use of DW_AT_ranges would invalidate it (& I /think/ many & perhaps most scopes are fragmented into ranges in optimized code which is where any of these stats are interesting) & basic block reordering, etc, is sort of the nail in the coffin.

"Yeah, that could be handy - but probably pretty complicated to propagate through the compiler & only have limited benefits to users (in normal debugger scenarios, rather than stats) - the difference between "this variable is out of scope" (or using another variable that would otherwise have been shadowed - that's pretty important) and "this variable's value is optimized out". The complexity of the implementation might be why it's not been implemented - possible that an implementation might be justifiable in a context of bigger improvements like is_stmt accuracy or sub-expression source range grouping, or other ideas that've been thrown around from time to time."


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70548/new/

https://reviews.llvm.org/D70548





More information about the llvm-commits mailing list