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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D69027#1712015 <https://reviews.llvm.org/D69027#1712015>, @krisb wrote:

> In D69027#1711682 <https://reviews.llvm.org/D69027#1711682>, @dblaikie wrote:
>
> > I'm confused - given the presence of noncontiguous ranges, why would the "first def" be an important property?
> >
> > The existence of this operation is "iffy" to me - I'd expect a general solution that handles all the noncontiguous range chunks equally, so there wouldn't be a special case for the "first def".
>
>
> Currently, we calculate the variable's coverage this way (if I understand the things correctly):
>
> 1. Calculate the size of the whole scope - subprogram, lexical block, etc (either as a distance between scope's HighPC or LowPC or a sum of sizes of scope's ranges).
> 2. Calculate the number of bytes where the variable is defined (by its location list).
> 3. Calculate and substruct OffsetToFirstDefinition from the size of the scope.
> 4. Divide the number of bytes where a variable is defined by the adjusted size of the scope. OffsetToFirstDefinition is applied in the case the variable first definition address greater than scope's LowPC. I guess this is done to handle cases where the variable is defined not in the beginning of the scope (e.g. in the middle of a function).


Ah, OK - thanks for the explanation! Yeah, makes sense - and your point about it potentially being optimistic is valid, and yeah, I don't have any great ideas (no way to know where the variable's value /should/ start).

I'll leave you & other folks who have more context with locstats to continue with this review - sorry for the diversion & thanks for walking me through it!

> Actually, I don't like this solution with OffsetToFirstDefinition because it makes the statistics more optimistic that it often is and hides some issues. But not sure alternatives are really better. 
>  So, in this patch, I try to fix some issues related to calculation and usage of OffsetToFirstDefinition. The major one is that the OffsetToFirstDefinition is calculated as a distance between the variable's first definition address and scope's LowPC, which will be obviously wrong in cases like this
> 
>   DW_TAG_lexical_block
>     DW_AT_ranges  (0x00000000
>        [0x0000000000000016, 0x0000000000000020)
>        [0x0000000000000183, 0x00000000000002f4))
>   
>     DW_TAG_variable
>       DW_AT_location  (0x0000018e
>          [0x0000000000000183,  0x0000000000000197): DW_OP_reg0 RAX)
> 
> 
> where we'd say the whole scope of the variable is covered.




Repository:
  rL LLVM

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

https://reviews.llvm.org/D69027