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

[Axel Hecht via llvm-dev]

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.

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 IPRAWITH IPRA
> ========================
> Total Build Time76 mins82.3 mins8% increment
> Octane v2.0 JS Benchmark Score (higher is better)18675.69 19665.165% 
> 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.10112.882.52% 
> improvement
>
> Any suggestions are welcome on how to effectively measure performance 
> improvement!
>
> Sincerely,
> Vivek
>
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/8854fba6/attachment.html>