[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