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

Djordje Todorovic via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 23 00:20:11 PDT 2021

(Sorry for the divergence)

Hi Amy,

Unfortunately running llvm-locstats fails on the chrome binary, so no coverage stats. Can you please file a bug against this, so we can take a look? I am wondering if the problem is on the llvm-locstats or on the llvm-dwarfdump --statistics side.

Best, Djordje

From: Jeremy Morse <jeremy.morse.llvm at gmail.com> Sent: Wednesday, August 18, 2021 10:30 PM To: Amy Huang <akhuang at google.com> Cc: 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: Re: [llvm-dev] Call for testing -- new variable location tracking solution

Hi Amy,

On Wed, Aug 18, 2021 at 8:58 PM Amy Huang <akhuang at google.com> wrote:

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.

Excellent, that's really reassuring given how large chrome is, thanks for trying a build with the flag,

Unfortunately running llvm-locstats fails on the chrome binary, so no coverage stats.

That's a shame; however I'm confident there won't be a coverage regression, detecting any performance cliff edges was my main aim here.

-- Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210823/6e660145/attachment.html>

More information about the llvm-dev mailing list