Jeremy Morse via llvm-dev
2021-Jul-28 17:11 UTC
[llvm-dev] 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
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>
Amy Huang via llvm-dev
2021-Aug-18 19:58 UTC
[llvm-dev] Call for testing -- new variable location tracking solution
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>