[llvm-dev] Call for testing -- new variable location tracking solution

[Djordje Todorovic via llvm-dev]

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