<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jeremy,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for doing this!</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="background-color:rgb(255, 255, 255);display:inline !important">(NOTE: the same code base was used for building both <span style="background-color:rgb(255, 255, 255);display:inline !important">gdb-built-with-llvm-trunk and </span>
<span style="background-color:rgb(255, 255, 255);display:inline !important">gdb-built-with-new-varloc-enabled.</span>)</span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The final locstats numbers look promising:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ llvm-locstats gdb-built-with-llvm-trunk</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
=================================================
<div> Debug Location Statistics</div>
<div> =================================================</div>
<div> cov% samples percentage(~)</div>
<div> -------------------------------------------------</div>
<div> 0% 2501 2%</div>
<div> (0%,10%) 5793 5%</div>
<div> [10%,20%) 4959 4%</div>
<div> [20%,30%) 4860 4%</div>
<div> [30%,40%) 4361 4%</div>
<div> [40%,50%) 4084 3%</div>
<div> [50%,60%) 4508 4%</div>
<div> [60%,70%) 4734 4%</div>
<div> [70%,80%) 5643 5%</div>
<div> [80%,90%) 6309 6%</div>
<div> [90%,100%) 10186 9%</div>
<div> 100% 45108 43%</div>
<div> =================================================</div>
<div> -the number of debug variables processed: 103046</div>
<div> -PC ranges covered: <span style="color: rgb(237, 92, 87);">57%</span></div>
<div> -------------------------------------------------</div>
<div> -total availability: 86%</div>
=================================================<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
$ llvm-locstats gdb-built-with-new-varloc-enabled</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
=================================================
<div> Debug Location Statistics</div>
<div> =================================================</div>
<div> cov% samples percentage(~)</div>
<div> -------------------------------------------------</div>
<div> 0% 2857 2%</div>
<div> (0%,10%) 5015 4%</div>
<div> [10%,20%) 4225 4%</div>
<div> [20%,30%) 4179 4%</div>
<div> [30%,40%) 3723 3%</div>
<div> [40%,50%) 3522 3%</div>
<div> [50%,60%) 3986 3%</div>
<div> [60%,70%) 4176 4%</div>
<div> [70%,80%) 5084 5%</div>
<div> [80%,90%) 5655 5%</div>
<div> [90%,100%) 8104 7%</div>
<div> 100% 51071 50%</div>
<div> =================================================</div>
<div> -the number of debug variables processed: 101597</div>
<div> -PC ranges covered: <span style="color: rgb(237, 92, 87);"><b>64%</b></span></div>
<div> -------------------------------------------------</div>
<div> -total availability: 85%</div>
=================================================<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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, t<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">he
number of debug variables generated is different</span><span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best regards,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Djordje</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jeremy Morse <jeremy.morse.llvm@gmail.com><br>
<b>Sent:</b> Wednesday, July 28, 2021 7:11 PM<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org>; Adrian Prantl <aprantl@apple.com>; Paul Robinson <paul.robinson@sony.com>; Eric Christopher <echristo@gmail.com>; Jonas Devlieghere <jdevlieghere@apple.com>; David Blaikie <dblaikie@gmail.com>; Reid Kleckner <rnk@google.com>;
Vedant Kumar <vsk@apple.com>; Djordje Todorovic <Djordje.Todorovic@syrmia.com>; Cazalet-Hyams, Orlando <orlando.hyams@sony.com>; Tozer, Stephen <Stephen.Tozer@sony.com><br>
<b>Subject:</b> Call for testing -- new variable location tracking solution</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hi llvm-dev@,<br>
<br>
tl;dr, If you build a large optimised x86 codebase with clang and want<br>
better variable locations when debugging, please consider testing the<br>
"-Xclang -fexperimental-debug-variable-locations" command line switch<br>
for clang.<br>
<br>
I've been putting together a new mechanism for tracking variable<br>
locations after instruction selection [0-2], and it's now reaching<br>
maturity. From r8612417e5a5 it's able to build stage2 clang, various<br>
benchmarks and a popular game engine, delivering improved variable<br>
location coverage as described in [2]. However, I fear the<br>
compile-time performance characteristics are going to be substantially<br>
different. I've tried my best to keep things fast, but when there's<br>
more data being produced there'll inevitably be some kind of slowdown,<br>
and it's hard to determine which workloads might be affected. Thus: if<br>
you'd like to lend a hand, please consider running a build with this<br>
flag, and see whether there's a disproportionate compile-time<br>
performance drop. CTMark times show a 1% to 5% performance cost right<br>
now [3], higher for -O0 [4] simply because I haven't focused on -O0<br>
(yet).<br>
<br>
There are a few more coverage-improving patches (such as D104519) that<br>
are yet to land / be published, but what's in-tree already gives good<br>
improvements versus DBG_VALUE-based tracking. Right now only x86 works<br>
really well -- I've made a start on aarch64 to ease adoption [5], but<br>
it's not all there yet.<br>
<br>
The overall mechanism involves annotating instructions with debugging<br>
information instead of attaching it to registers. As a consequence,<br>
additional book-keeping is needed in target-specific optimisations.<br>
Adding that support is probably more a marathon than a sprint;<br>
documenting exactly what needs to be done is in the "TODO" column too.<br>
<br>
We could consider turning this feature on by default for major targets<br>
sometime around llvm-14; I don't have a plan for that yet, but<br>
previous feedback has been positive and the coverage improvements are<br>
encouraging.<br>
<br>
[0] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html">
https://lists.llvm.org/pipermail/llvm-dev/2020-February/139440.html</a><br>
[1] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-June/142368.html">https://lists.llvm.org/pipermail/llvm-dev/2020-June/142368.html</a><br>
[2] <a href="https://lists.llvm.org/pipermail/llvm-dev/2020-November/146444.html">
https://lists.llvm.org/pipermail/llvm-dev/2020-November/146444.html</a><br>
[3] <a href="http://llvm-compile-time-tracker.com/compare.php?from=28ec787eca6ca5460fac9e0f9235bd89436309d0&to=3313f75407bf1f1f4dd787e5233d99cc9e42ba55&stat=instructions">
http://llvm-compile-time-tracker.com/compare.php?from=28ec787eca6ca5460fac9e0f9235bd89436309d0&to=3313f75407bf1f1f4dd787e5233d99cc9e42ba55&stat=instructions</a><br>
[4] <a href="http://llvm-compile-time-tracker.com/compare.php?from=bc06b434f0309a9d731f02561301867adeccc622&to=28ec787eca6ca5460fac9e0f9235bd89436309d0&stat=instructions">
http://llvm-compile-time-tracker.com/compare.php?from=bc06b434f0309a9d731f02561301867adeccc622&to=28ec787eca6ca5460fac9e0f9235bd89436309d0&stat=instructions</a><br>
[5] See stack at <a href="https://reviews.llvm.org/D104519">https://reviews.llvm.org/D104519</a><br>
<br>
--<br>
Thanks,<br>
Jeremy<br>
</div>
</span></font></div>
</body>
</html>