[llvm-dev] Call for testing -- new variable location tracking solution
Djordje Todorovic via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 29 05:40:38 PDT 2021
Hi Jeremy,
Thanks for doing this!
I was playing a bit with this and I have used gdb-7.11 as a testbed (compiled for X86_64, with -g -O2 by using llvm-trunk on RHEL7).
(NOTE: the same code base was used for building both gdb-built-with-llvm-trunk and gdb-built-with-new-varloc-enabled.)
The final locstats numbers look promising:
$ llvm-locstats gdb-built-with-llvm-trunk
=================================================
Debug Location Statistics
=================================================
cov% samples percentage(~)
-------------------------------------------------
0% 2501 2%
(0%,10%) 5793 5%
[10%,20%) 4959 4%
[20%,30%) 4860 4%
[30%,40%) 4361 4%
[40%,50%) 4084 3%
[50%,60%) 4508 4%
[60%,70%) 4734 4%
[70%,80%) 5643 5%
[80%,90%) 6309 6%
[90%,100%) 10186 9%
100% 45108 43%
=================================================
-the number of debug variables processed: 103046
-PC ranges covered: 57%
-------------------------------------------------
-total availability: 86%
=================================================
$ llvm-locstats gdb-built-with-new-varloc-enabled
=================================================
Debug Location Statistics
=================================================
cov% samples percentage(~)
-------------------------------------------------
0% 2857 2%
(0%,10%) 5015 4%
[10%,20%) 4225 4%
[20%,30%) 4179 4%
[30%,40%) 3723 3%
[40%,50%) 3522 3%
[50%,60%) 3986 3%
[60%,70%) 4176 4%
[70%,80%) 5084 5%
[80%,90%) 5655 5%
[90%,100%) 8104 7%
100% 51071 50%
=================================================
-the number of debug variables processed: 101597
-PC ranges covered: 64%
-------------------------------------------------
-total availability: 85%
=================================================
The thing I am concerned about is the number of 0% covered variables. It has increased when using this new feature, and I was wondering if there is any reason for that. In addition, the number of debug variables generated is different.
Furthermore, when using llvm-dwarfdump --statistics, I am seeing some differences in some numbers (e.g. #call site DIEs (this might indicate that generated code has changed?), #params (num of DW_TAG_formal_parameter), etc.).
Best regards,
Djordje
________________________________
From: Jeremy Morse <jeremy.morse.llvm at gmail.com>
Sent: Wednesday, July 28, 2021 7:11 PM
To: llvm-dev <llvm-dev at lists.llvm.org>; Adrian Prantl <aprantl at apple.com>; Paul Robinson <paul.robinson at sony.com>; Eric Christopher <echristo at gmail.com>; Jonas Devlieghere <jdevlieghere at apple.com>; David Blaikie <dblaikie at gmail.com>; Reid Kleckner <rnk at google.com>; Vedant Kumar <vsk at apple.com>; Djordje Todorovic <Djordje.Todorovic at syrmia.com>; Cazalet-Hyams, Orlando <orlando.hyams at sony.com>; Tozer, Stephen <Stephen.Tozer at sony.com>
Subject: Call for testing -- new variable location tracking solution
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210729/444353e2/attachment.html>
More information about the llvm-dev
mailing list