[llvm-dev] Call for testing -- new variable location tracking solution

[Jeremy Morse via llvm-dev]

Hi Caroline,

On Thu, Sep 2, 2021 at 4:29 PM Caroline Tice <cmtice at google.com> wrote:
>  I ran some  tests using this flag on a large set of tests inside Google and saw only very slight degradations (~1%) in memory usage and wall clock time.

That's great to hear, and highly encouraging that there's no
significant increase in resource usage, thanks for testing out the
flag,

> The ratio sum_all_params(#bytes in parent scope covered by DW_AT_location)/#bytes in parent scope) improved (increased) by 6-8%.
>
> The ratio of sum_all_variables(#bytes in parent scope covered by DW_AT_location)/#bytes in parent scope *mostly* improved (increased) 3-4%.  One extremely large program had a 22% improvement.  However another very large program had a 30% regression.
>
> The ratio of local_vars_bytes_with_locations:sum_all_local_vars(#bytes in parent scope covered by DW_AT_location)/#bytes in parent scope also showed regressions in those two large programs.
>
> The ratio of sum_all_params(#bytes in parent scope covered by DW_OP_entry_value)/#bytes in parent scope showed 2-4% improvements across all the test programs.

These improvements are encouraging too; the magnitude of the outliners
(22% up, 30% down) are surprising, especially on large codebases. I'm
aware of a few issues that lose coverage versus the current
location-based tracking, storing subregisters to the stack and when
register spills are fused into other instructions. (I have patches,
although they're yet to land). It's possible that those will rectify
some of the coverage regression.

I don't have a good explanation for the 22% increase; it does sound
too good to be true. If you have any spare cycles, looking at the
coverage gains and judging whether they're false locations or true
gains would be appreciated.

--
Thanks,
Jeremy