<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 8:58 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jun 20, 2016, at 3:22 PM, vivek pandya via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 10:06 PM, Davide Italiano<span> </span><span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Sun, Jun 19, 2016 at 11:41 AM, vivek pandya via llvm-dev<br><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>> Hello,<br>><br>> I build FireFox-46.0.1 source with llvm to test interprocedural register<br>> allocation.<br>> The build was successful with out any runtime faliures, here are few stats:<br><br></span>This is very good, thanks for working on this.<br><span><br>><br>> Measure W/O IPRA WITH IPRA<br>> ======= ======== =========<br>> Total Build Time 76 mins 82.3 mins 8% increment<br>> Octane v2.0 JS Benchmark Score (higher is better) 18675.69  19665.16 5%<br>> improvement<br><br></span>This speedup is kind of amazing, enough to make me a little bit suspicious.<br>From what I can see, Octane is not exactly a microbenchmark but tries<br>to model complex/real-world web applications, so, I think you might<br>want to analyze where this speedup is coming from?</blockquote><div>Hi Davide,</div><div><br></div><div>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. </div></div></div></div></div></blockquote><div><br></div></span><div>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).</div><div>Here is a possible way:</div><div><br></div><div>1) Find one or two benchmarks that show the most improvements.</div><div>2) Run with and without IPRA in a profiler (Instruments or other).</div><div>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.</div><div><br></div></div></div></blockquote><div>I have tried some test case which has run time improvements and top most such cases where not benefited by IPRA but change of code gen order to be on call graph. I was able to verify it as most of those test cases have very few functions and inside that function there are library calls like printf so IPRA can not help much there. But one test case in which there is around 4% performance improvement test-suite/MultiSource/Benchmarks/FreeBench/pifft that I tried out and generated assembly file for IPRA and NO_IPRA run and comparing those files can show IPRA improves code quality by avoiding no of spills/restore mainly. </div><div>Please check generated assembly here: <a href="https://gist.github.com/vivekvpandya/081baba01196c705f8b9baf420d960a1/revisions">https://gist.github.com/vivekvpandya/081baba01196c705f8b9baf420d960a1/revisions</a></div><div><br></div><div>how ever these functions are not really on hot path ( according to Instruments app) but still functions like mp_add , mp_sub has about  9 call sites so I think this justifies improvements due to IPRA. I have also compared some assembly for some large functions (~2000 lines of assembly code) from sqlite3 source code and observed that in such large functions IPRA is able to save good number of spills. </div><div><br></div><div>Sincerely,</div><div>Vivek</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div><br></div><div>— </div><div>Mehdi</div><div><br></div><br><blockquote type="cite"><div><span class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also, "score" might<br>be a misleading metric, can you actually elaborate what that means?<br>How does that relate to, let's say, runtime performance improvement?<br></blockquote><div>Octane score considers 2 things execution speed and latency (pause during execution) . You can find more information here <a href="https://developers.google.com/octane/faq" target="_blank">https://developers.google.com/octane/faq</a></div><div><br></div><div>-Vivek</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Thanks!<br><span><font color="#888888"><br>--<br>Davide<br><br>"There are no solved problems; there are only problems that are more<br>or less solved" -- Henri Poincare<br></font></span></blockquote></div><br></div></div></span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">LLVM Developers mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:llvm-dev@lists.llvm.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">llvm-dev@lists.llvm.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></div></blockquote></div><br></div></blockquote></div><br></div></div>