[llvm-dev] FireFox-46.0.1 build with interprocedural register allocation enabled

[vivek pandya via llvm-dev]

On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano <davide at freebsd.org>
wrote:

> On Sun, Jun 19, 2016 at 11:41 AM, vivek pandya via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Hello,
> >
> > I build FireFox-46.0.1 source with llvm to test interprocedural register
> > allocation.
> > The build was successful with out any runtime faliures, here are few
> stats:
>
> This is very good, thanks for working on this.
>
> >
> > Measure W/O IPRA WITH IPRA
> > ======= ======== =========
> > Total Build Time 76 mins 82.3 mins 8% increment
> > Octane v2.0 JS Benchmark Score (higher is better) 18675.69  19665.16 5%
> > improvement
>
> This speedup is kind of amazing, enough to make me a little bit suspicious.
> From what I can see, Octane is not exactly a microbenchmark but tries
> to model complex/real-world web applications, so, I think you might
> want to analyze where this speedup is coming from?

Hi Davide,

I don't understand much about browser benchmarks but what IPRA is trying to
do is reduce spill code , and trying to keep values in register where ever
it can so speed up is comping from improved code quality. But with current
infrastructure it is hard to tell which particular functions in browser
code is getting benefitted.

> Also, "score" might
> be a misleading metric, can you actually elaborate what that means?
> How does that relate to, let's say, runtime performance improvement?
>
Octane score considers 2 things execution speed and latency (pause during
execution) . You can find more information here
https://developers.google.com/octane/faq

-Vivek

>
> Thanks!
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/8dee5c9d/attachment.html>