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

[Jeremy Morse via llvm-dev]

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