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

[Amy Huang via llvm-dev]

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>