[llvm-dev] Call for testing -- new variable location tracking solution (original) (raw)

Amy Huang via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 18 12:58:03 PDT 2021

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 DBGVALUE-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>

More information about the llvm-dev mailing list