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

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 20 17:28:31 PDT 2016

On Mon, Jun 20, 2016 at 12:22 PM, vivek pandya <vivekvpandya at gmail.com> wrote:
> 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.

It sounds a little bit weird that you see such a big improvement for a
benchmark that's supposed to exercise JS (which is very likely handled
by a JIT inside FF), that's why I asked. My point (and worry) is that
benchmarks are very hard to get right, and from time to time you might
end up getting better numbers because of noise and not for 'improved
code quality'.
In other words, as you're presenting numbers, you should be able to
defend those numbers with an analysis which explains why your pass
makes the code better. Hope this makes sense.


"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

More information about the llvm-dev mailing list