[PATCH] D69027: [llvm-dwarfdump][Statistics] Fix calculation of OffsetToFirstDefinition

Kristina Bessonova via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 31 16:07:52 PDT 2019


krisb added a comment.

In D69027#1729302 <https://reviews.llvm.org/D69027#1729302>, @dblaikie wrote:

> In D69027#1728152 <https://reviews.llvm.org/D69027#1728152>, @aprantl wrote:
>
> > I see the primary value of this statistic to allow us to see change — then a human has to make judgement what that change means. Regardless which choice we make, we may get a false signal from a compiler change that reorders basic blocks, but we'll get valuable signal when we're testing the ramifications of a debug-info-only change to the compiler. As long as we document what the statistics measure, I think we just need to pick something and run with it.
>
>
> Sure - then I'd suggest that a good statistic to choose would be "bytes covered by location lists" (which is already there) and maybe, if you want a % one, "bytes covered by location lists" / "bytes of enclosing scopes" (counting each scope once for each variable within it - or doing the loc-list-intersects-with-enclosing-scope earlier & just tracking the relative numbers from that point).


Looks like I missed this message while writing my previous one, sorry. 
I strongly agree here. As I said at the beginning of the discussion if to give up guessing about the variable's scope, the only statistic that makes sense is "bytes covered by location lists". 
But what about others we already have? Should they be considered as 'not useful' or 'not reliable'? I still think that measurements against some kind of 'adjusted' scope can be quite useful.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D69027





More information about the llvm-commits mailing list