llvm dev - Aug 2021 - Call for testing -- new variable location tracking solution

Hi!

Just wanted to say I've tried building Chrome with this (with -g2 -O2) on
Linux and didn't see a noticeable difference in compile time.
Unfortunately running llvm-locstats fails on the chrome binary, so no
coverage stats.

-Amy

On Wed, Jul 28, 2021 at 10:12 AM Jeremy Morse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi llvm-dev@,
>
> tl;dr, If you build a large optimised x86 codebase with clang and want
> better variable locations when debugging, please consider testing the
> "-Xclang -fexperimental-debug-variable-locations" command line
switch
> for clang.
>
> I've been putting together a new mechanism for tracking variable
> locations after instruction selection [0-2], and it's now reaching
> maturity. From r8612417e5a5 it's able to build stage2 clang, various
> benchmarks and a popular game engine, delivering improved variable
> location coverage as described in [2]. However, I fear the
> compile-time performance characteristics are going to be substantially
> different. I've tried my best to keep things fast, but when there's
> more data being produced there'll inevitably be some kind of slowdown,
> and it's hard to determine which workloads might be affected. Thus: if
> you'd like to lend a hand, please consider running a build with this
> flag, and see whether there's a disproportionate compile-time
> performance drop. CTMark times show a 1% to 5% performance cost right
> now [3], higher for -O0 [4] simply because I haven't focused on -O0
> (yet).
>
> There are a few more coverage-improving patches (such as D104519) that
> are yet to land / be published, but what's in-tree already gives good
> improvements versus DBG_VALUE-based tracking. Right now only x86 works
> really well -- I've made a start on aarch64 to ease adoption [5], but
> it's not all there yet.
>
> The overall mechanism involves annotating instructions with debugging
> information instead of attaching it to registers. As a consequence,
> additional book-keeping is needed in target-specific optimisations.
> Adding that support is probably more a marathon than a sprint;
> documenting exactly what needs to be done is in the "TODO" column
too.
>
> We could consider turning this feature on by default for major targets
> sometime around llvm-14; I don't have a plan for that yet, but
> previous feedback has been positive and the coverage improvements are
> encouraging.
>
> [0] https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html
> [1] https://lists.llvm.org/pipermail/llvm-dev/2020-June/142368.html
> [2] https://lists.llvm.org/pipermail/llvm-dev/2020-November/146444.html
> [3]
>
http://llvm-compile-time-tracker.com/compare.php?from=28ec787eca6ca5460fac9e0f9235bd89436309d0&to=3313f75407bf1f1f4dd787e5233d99cc9e42ba55&stat=instructions
> [4]
>
http://llvm-compile-time-tracker.com/compare.php?from=bc06b434f0309a9d731f02561301867adeccc622&to=28ec787eca6ca5460fac9e0f9235bd89436309d0&stat=instructions
> [5] See stack at https://reviews.llvm.org/D104519
>
> --
> Thanks,
> Jeremy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210818/0db88692/attachment.html>

Hi Amy,

On Wed, Aug 18, 2021 at 8:58 PM Amy Huang <akhuang at google.com>
wrote:
> Just wanted to say I've tried building Chrome with this (with -g2 -O2)
on Linux and didn't see a noticeable difference in compile time.
Excellent, that's really reassuring given how large chrome is, thanks
for trying a build with the flag,
> Unfortunately running llvm-locstats fails on the chrome binary, so no
coverage stats.
That's a shame; however I'm confident there won't be a coverage
regression, detecting any performance cliff edges was my main aim
here.

--
Thanks,
Jeremy

Just FYI.

 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.

Focusing on optimized builds (-O3) with debug information on a
representative set of medium-to-large programs,

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.

Unsurprisingly, the size of debug_loclists increased 5-11%.

If you want more details, let me know.

-- Caroline Tice
cmtice at google.com


On Wed, Aug 18, 2021 at 1:31 PM Jeremy Morse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Amy,
>
> On Wed, Aug 18, 2021 at 8:58 PM Amy Huang <akhuang at google.com>
wrote:
> > Just wanted to say I've tried building Chrome with this (with -g2
-O2)
> on Linux and didn't see a noticeable difference in compile time.
>
> Excellent, that's really reassuring given how large chrome is, thanks
> for trying a build with the flag,
>
> > Unfortunately running llvm-locstats fails on the chrome binary, so no
> coverage stats.
>
> That's a shame; however I'm confident there won't be a coverage
> regression, detecting any performance cliff edges was my main aim
> here.
>
> --
> Thanks,
> Jeremy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210902/02e4298d/attachment.html>