Djordje Todorovic via llvm-dev
2021-Jul-29 12:40 UTC
[llvm-dev] Call for testing -- new variable location tracking solution
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>
Jeremy Morse via llvm-dev
2021-Jul-29 13:19 UTC
[llvm-dev] Call for testing -- new variable location tracking solution
Hi Djordje, It's great to see that improvement in coverage, particularly when not all the improvements are landed yet. Note that some substantial portion of the new locations might be entry values, knowing the desired values of variables lets us better identify when entry values can be used, On Thu, Jul 29, 2021 at 1:40 PM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote:> 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.Several things could be going on here, my bet would be that it's related to D95617 -- unfortunately the different ways that we represent variables that have been optimised out can have an effect on the DWARF produced. David points out in this comment [0] that the fix isn't complete (non-inline functions with abstract origins can gain/lose variables depending on our internal representation), I took a look but fixing it wasn't straight forwards (I think subprograms can acquire abstract origins after they're dwarf-emitted?). That could explain why there are more zero-percent variables in the output (different representation leads to different variable count); however the total number of variables _decreases_, which I wouldn't expect. If you can get a small reproducer for that I'd really like to look at it. [0] https://reviews.llvm.org/D95617#2672839 -- Thanks, Jeremy