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

[Madhur Amilkanthwar via llvm-dev]

I too agree with the general consensus that the benchmarks
are hard to get are hard to trust on. Moreover, profiling at
function level is also cumbersome.

However,
1. what we want to know (directly or indirectly) is how many
registers we saved in *hot* path?
2. How much time we saved in spill-refill?
3. What is causing the regression?

and I think as long we focus on this data, we can surely conclude that
the change has a sterling impact.



On Tue, Jun 21, 2016 at 7:48 PM, vivek pandya via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Tue, Jun 21, 2016 at 1:59 PM, Axel Hecht <l10n at mozilla.com> wrote:
>
>> Hi,
>>
>> the best way to move forward, and I guess the answer to your question, is
>> to get your work to build and test on try.
>>
>> And now I'm going to flood you with jargon, sorry. Instead of trying to
>> document that all here, I suggest you ask people for help on irc. Notably,
>> #taskcluster, and #build. Folks there are your target audience for compiler
>> changes, too.
>>
>> First read is https://wiki.mozilla.org/ReleaseEngineering/TryServer,
>> just to get the first piece of jargon out.
>>
>> I suspect that the next steps are:
>>
>> I speculate that you can use your version of llvm if you can create a
>> docker image that is able to compile Firefox. Please confirm that with
>> #taskcluster, and get some help there on how to do that.
>>
>> Then you'd want to make sure that you can actually compile/run
>> mozilla-central. In particular wrt to taskcluster, there's been various
>> file moves and changes, so working off of release is going to make your
>> path rockier. I understand that mozilla-central is more of a moving target,
>> but that shouldn't be that much of a problem for you in practice, I hope.
>>
>> I suspect that just focusing on linux x64 is good for you for now?
>>
>> So jargon-thought-train:
>>
>> Validate my assumptions about all of this ;-) .
>>
>> Make your setup work with mozilla-central.
>>
>> Work in docker.
>>
>> Make your mozilla-central's taskcluster tasks for linux x64 pick your
>> docker image to build on try.
>>
>> Push to try for linux x64, with all tests and perf tests.
>>
>> Use treeherder and perfherder (web uis) to see tests and performance.
>>
>>
>> If you want to focus on your toolchain impact over time instead of
>> mozilla-central, I think you should be able to keep the same base version
>> of your patch and just update the docker image, and then use perfherder to
>> compare the results.
>>
>> Hello Axel,
>
> This seems good plan but I think I would require time to setup all these,
> so I prefer to do this during next weekend.
>
> Thanks,
> Vivek
>
>> HTH
>>
>> Axel
>>
>> On 19/06/16 20:41, vivek pandya 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:
>>
>> 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
>> Kraken JS Benchmark time (lower is better) 1416.2 ms 1421.3 ms 0.35%
>> regression
>> JetStream JS Benchmark Score (higer is better) 110.10 112.88 2.52%
>> improvement
>>
>> Any suggestions are welcome on how to effectively measure performance
>> improvement!
>>
>> Sincerely,
>> Vivek
>>
>>
>>
>> _______________________________________________
>> firefox-dev mailing listfirefox-dev at mozilla.orghttps://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160622/d7dfc1c8/attachment.html>