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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

I was going to say that Alexey's diversion was derailing this review a bit - but as I've thought about it some more, I think there are some trickier problems with this idea:

The order of instructions and blocks is non-specific, we don't really know which is the "first" block in a scope - there's no reason that the execution order of the blocks need be the same as the address order, or the order they are emitted into the range list (which doesn't have to be in either order - so there's 3 possible orderings of blocks (& of course the "scope" ordering might not even be a unique ordering, it could start in the middle of a loop, different bits reachable in different orders, etc))

I guess even for a contiguous range of both the scope and the location, the basic blocks might be out of order (the earlier/lower instructions might represent later execution).
eg: you could have a scope of [10, 20) and a location that is [10, 5) + [7, 10) - but those 2 missing bytes (bytes 5 and 6) could be due to the start of the variable's lifetime (ie: they could be instructions related to code that appears before the variable is declared in the source).

And you could be in that situation where some basic block reordering means the "tail" of the scope, in machine instructions is actually code related to the start of the scope & prior to the variable's declaration.

So, yeah, I'm starting to feel like this "trim the start of the scope" bit is perhaps not a very good heuristic. You could trim /every/ range chunk separately - but you'd want to trim both the start and the end.

All this is to say, I'm coming around to the idea that it's difficult to impossible to have a metric that will even give you a vaguely confident number about whether we've described a variable's value across its entire scope.

But I think this is more @aprantl 's wheelhouse, since he created these statistics - so, Adrian, it'd be super useful if you could chime in here on what you think is useful to you/what you want to see in these features.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D69027