[llvm-dev] FireFox-46.0.1 build with interprocedural register allocation enabled
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 20 20:28:18 PDT 2016
> On Jun 20, 2016, at 3:22 PM, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano <davide at freebsd.org <mailto: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 <mailto: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.
You need to confirm that speedups are not “luck” (for instance by removing a spill you changed the code alignment, or just having the code layout in a CGSCC order that would make a difference).
Here is a possible way:
1) Find one or two benchmarks that show the most improvements.
2) Run with and without IPRA in a profiler (Instruments or other).
3) Disassemble the hot path and try to figure out why. To confirm your findings (i.e. If you find a set of functions / call-sites) that you think are responsible for the speedup, you can try to bisect by forcing IPRA to run only on selected functions.
> 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 <https://developers.google.com/octane/faq>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev