<div dir="ltr">Hi Yin,<div><br></div><div>Sorry that previously I didn't notice command line option "<b>-mllvm -inline-perf-mode=true</b>", because your test case doesn't show that. So now I measured performance on cortex-a57 again with command line option "<b>-mllvm -greedy-inliner=true -mllvm -inline-perf-mode=true</b>".</div>
<div><br></div><div><div>spec2000<span class="" style="white-space:pre"> </span>greedy_inliner_perf<span class="" style="white-space:pre"> </span>Threshold_1000_perf<span class="" style="white-space:pre"> </span>greedy_inliner_code_size<span class="" style="white-space:pre"> </span>threshold_1000_code_size</div>
<div>164.gzip<span class="" style="white-space:pre"> </span>0.00%<span class="" style="white-space:pre"> </span>-0.78%<span class="" style="white-space:pre"> </span>6.25%<span class="" style="white-space:pre"> </span>14.55%</div>
<div>175.vpr<span class="" style="white-space:pre"> </span>-4.09%<span class="" style="white-space:pre"> </span>-3.14%<span class="" style="white-space:pre"> </span>1.84%<span class="" style="white-space:pre"> </span>14.49%</div>
<div>176.gcc<span class="" style="white-space:pre"> </span>0.83%<span class="" style="white-space:pre"> </span>0.83%<span class="" style="white-space:pre"> </span>0.08%<span class="" style="white-space:pre"> </span>33.16%</div>
<div>181.mcf<span class="" style="white-space:pre"> </span>0.00%<span class="" style="white-space:pre"> </span>0.00%<span class="" style="white-space:pre"> </span>3.58%<span class="" style="white-space:pre"> </span>19.58%</div>
<div>186.crafty<span class="" style="white-space:pre"> </span>-0.93%<span class="" style="white-space:pre"> </span>1.85%<span class="" style="white-space:pre"> </span>-0.94%<span class="" style="white-space:pre"> </span>14.38%</div>
<div>197.parser<span class="" style="white-space:pre"> </span>-1.61%<span class="" style="white-space:pre"> </span>-2.24%<span class="" style="white-space:pre"> </span>-0.04%<span class="" style="white-space:pre"> </span>1.48%</div>
<div>252.eon<span class="" style="white-space:pre"> </span>-7.30%<span class="" style="white-space:pre"> </span>-6.52%<span class="" style="white-space:pre"> </span>2.64%<span class="" style="white-space:pre"> </span>6.42%</div>
<div>253.perlbmk<span class="" style="white-space:pre"> </span>-2.38%<span class="" style="white-space:pre"> </span>-3.76%<span class="" style="white-space:pre"> </span>-1.75%<span class="" style="white-space:pre"> </span>2.22%</div>
<div>254.gap<span class="" style="white-space:pre"> </span>0.00%<span class="" style="white-space:pre"> </span>-1.72%<span class="" style="white-space:pre"> </span>2.93%<span class="" style="white-space:pre"> </span>18.44%</div>
<div>255.vortex<span class="" style="white-space:pre"> </span>-1.04%<span class="" style="white-space:pre"> </span>-4.19%<span class="" style="white-space:pre"> </span>3.40%<span class="" style="white-space:pre"> </span>47.07%</div>
<div>256.bzip2<span class="" style="white-space:pre"> </span>1.40%<span class="" style="white-space:pre"> </span>-1.83%<span class="" style="white-space:pre"> </span>2.23%<span class="" style="white-space:pre"> </span>10.11%</div>
<div>300.twolf<span class="" style="white-space:pre"> </span>1.87%<span class="" style="white-space:pre"> </span>-0.36%<span class="" style="white-space:pre"> </span>-1.87%<span class="" style="white-space:pre"> </span>23.48%</div>
<div>177.mesa<span class="" style="white-space:pre"> </span>-3.36%<span class="" style="white-space:pre"> </span>-2.52%<span class="" style="white-space:pre"> </span>0.48%<span class="" style="white-space:pre"> </span>35.04%</div>
<div>179.art<span class="" style="white-space:pre"> </span>1.37%<span class="" style="white-space:pre"> </span>0.00%<span class="" style="white-space:pre"> </span>0.45%<span class="" style="white-space:pre"> </span>9.26%</div>
<div>183.equake<span class="" style="white-space:pre"> </span>-4.35%<span class="" style="white-space:pre"> </span>-5.80%<span class="" style="white-space:pre"> </span>1.67%<span class="" style="white-space:pre"> </span>23.23%</div>
<div>188.ammp<span class="" style="white-space:pre"> </span>0.35%<span class="" style="white-space:pre"> </span>1.75%<span class="" style="white-space:pre"> </span>0.07%<span class="" style="white-space:pre"> </span>6.69%</div>
</div><div><br></div><div>So now this performance result looks quite promising!<br></div><div><br></div><div>For xxx_perf, the negative number means running time is reduced and performance is better.</div><div>For xxx_codesize, the number is only for .text section.</div>
<div><br></div><div>From this result we can see,</div><div><br></div><div>1) The greedy inliner obtained the similar performance improvement as setting threshold to be 1000 with the original inliner.</div><div>2) But comparing with the significant code size bloat, the code size change of greedy inliner is quite limited on average.</div>
<div><br></div><div>Thanks,<br></div><div>-Jiangning</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-05 17:11 GMT+08:00 Jiangning Liu <span dir="ltr"><<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Yin,</div><div><br></div><div>I don't see performance improvement on cortex-a57 for eon with your patch, and spec2000/int data is as below, (negative is good)</div>
<div><br></div><div><div>164.gzip<span style="white-space:pre-wrap"> </span>0.00%</div>
<div>175.vpr<span style="white-space:pre-wrap"> </span>-4.55%</div><div>176.gcc<span style="white-space:pre-wrap"> </span>0.83%</div><div>181.mcf<span style="white-space:pre-wrap"> </span>0.00%</div><div>186.crafty<span style="white-space:pre-wrap"> </span>0.00%</div>
<div>197.parser<span style="white-space:pre-wrap"> </span>-2.26%</div><div>252.eon<span style="white-space:pre-wrap"> </span>1.46%</div><div>253.perlbmk<span style="white-space:pre-wrap"> </span>5.24%</div><div>
254.gap<span style="white-space:pre-wrap"> </span>0.88%</div><div>255.vortex<span style="white-space:pre-wrap"> </span>-0.52%</div><div>256.bzip2<span style="white-space:pre-wrap"> </span>0.47%</div><div>300.twolf<span style="white-space:pre-wrap"> </span>1.87%</div>
</div><div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-05 10:52 GMT+08:00 Jiangning Liu <span dir="ltr"><<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yin,<div><br></div><div>I got the following "make check-all" failure.</div><div><br></div><div>
<div>/home/jialiu01/llvm/llvm/tools/clang/test/Driver/greedy-inliner.c:8:11: error: expected string not found in input</div>
<div>// CHECK: Greedy Inliner</div><div> ^</div><div><stdin>:1:1: note: scanning from here</div><div>clang (LLVM option parsing): for the -print-after option: Cannot find option named 'greedy-inliner'!</div>
<div>^</div></div><div><br></div><div>Can you confirm that is an issue?</div><div><br></div><div>And for performance, I haven't got the data on Cortex-A57 yet, and I will let you know as soon as I get the result. For Cortex-A53, I never try it before.</div>
<div><br></div><div>Thanks,</div><div>-Jiangning</div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-05 6:06 GMT+08:00 Yin Ma <span dir="ltr"><<a href="mailto:yinma@codeaurora.org" target="_blank">yinma@codeaurora.org</a>></span>:<div>
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thank Jiangning for a comprehensive testing for Greedy inliner. I am aware of Chandler's discussion about rewriting the pass manager in order to overcome the limitation of current inliner and the intension toward the perfect solution. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But we had to provide an inliner solution to address some LLVM performance degradation compared to GCC. That is how the greedy inliner was born. This inliner is a module pass, it does not have the SCC<->function analysis problem. Note that the Greedy inliner is a flexible solution, it can be set up to be either a bottom up, top down or other custom order (that is the purpose of using a queue with sorted weights).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regarding code size, for our internal very large C++ code base, the Greedy inliner did better job compared with SCC inliner at -Os. It was able to inline more functions than the SCC inliner without increasing code size. In one instance the generated file by either inliner approaches was quite similar size. However, looking at the number of entries in the symbol table, the Greedy inliner version had 540880 entries, while the SCC inliner version had 619639 entries. This was achieved by setting weights to favor top down order. Chandler, if you have any large code base examples in mind, I would like to try. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regarding performance, the Greedy inliner has also shown better performance than the SCC inliner. I already reported the gains for SPEC2000 (eon 16%, mesa 5%) without any degradation of other tests. Jiangning also verified it independently. This was achieved by setting weights to favor call sites in loops.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For virtual dispatch, we didn't see any C++ virtual dispatch problem exposed when evaluating the Greedy inliner because greedy inliner reused the SCC inliner to do the local decision. If anyone has a test case for this or program in mind, I can try to run it and report the findings.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I like the suggestion from Hal to have a "more in-depth discussion on the goals of inlining, and how we do, or plan to, achieve them." Since now we have two concrete solutions for inliners, how about we have BOF discussion at the LLVM dev conference? I can send a proposal.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What do you guys think?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Here are some details on the scenarios we considered when tuning the greedy inliner and other possible future scenarios. The first one is A <- B <- C case mentioned, B is in a loop of A. B to A should be higher priority to be considered before C to B <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A() {<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For(..) { Call B() }<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">B() {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> call C()<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The second is A called B many times, one bar is in a loop that need to be inlined. B() instead loops should have higher priority to be considered than other B in A(). other B may not be benefitical to be inlined for code size tuning.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A() {<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Call B()<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Call B()<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Call B()<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For(...) { Call B() }<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Call B()<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The third is a series of continue calls, in the architecture we targeted on, we don't want to inline them. Inliner should have a global sense to do the decision.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">A() {<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If (...) {<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B(); <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B(); <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}else if {<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Call B();<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}else ...<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">...<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">}<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The next one is a future scenario that supports profile based decision. I considered this case but not implemented in the current version of greey inliner. Block frequency info can be used in computation to guide order and decision.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The key to take into account top-down/bottom up differences and the scenarios described above is to have an inliner framework that has the concept of a global queue with sorted weights. It is a very flexible framework. Any future LLVM inliner solution we decide on should support this type of feature.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yin<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvm-commits-bounces@cs.uiuc.edu" target="_blank">llvm-commits-bounces@cs.uiuc.edu</a>] <b>On Behalf Of </b>Chandler Carruth<br>
<b>Sent:</b> Sunday, August 03, 2014 11:51 PM<br><b>To:</b> Jiangning Liu<br><b>Cc:</b> Jiangning Liu; Commit Messages and Patches for LLVM</span></p><div><br><b>Subject:</b> Re: [PATCHES] A module inliner pass with a greedy call site queue<u></u><u></u></div>
<p></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Just a brief note...<u></u><u></u></p></div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Sun, Aug 3, 2014 at 11:42 PM, Jiangning Liu <<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>> wrote:<u></u><u></u></p>
<div><p class="MsoNormal">1. I measured code size impact by Yin's patch, overall I don't see code size regression.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
1) For the following cpp program in SPEC, we have the following data.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-O2 result:<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><div><p class="MsoNormal">spec old_text_section old_data_section new_text_section new_text_section text_percentage data_percentage<u></u><u></u></p></div></div><div><p class="MsoNormal">252.eon 302848 2232 297301 2312 -1.83% 3.58%<u></u><u></u></p>
</div><div><div><p class="MsoNormal">450.soplex 366474 1536 389164 1656 6.19% 7.81%<u></u><u></u></p></div><div><p class="MsoNormal">453.povray 898032 12632 850444 12632 -5.30% 0.00%<u></u><u></u></p></div><div><p class="MsoNormal">
471.omnetpp 685516 9136 693349 9128 1.14% -0.09%<u></u><u></u></p></div><div><p class="MsoNormal">473.astar 38999 860 41011 860 5.16% 0.00%<u></u><u></u></p></div><div><p class="MsoNormal">483.xalancbmk 4282478 139376 4414286 139376 3.08% 0.00%<u></u><u></u></p>
</div><div><p class="MsoNormal">sum 6574347 165772 6685555 165964 1.69% 0.12%<u></u><u></u></p></div></div></div><p class="MsoNormal"><br>SPEC is highly misleading w.r.t. code size. Also, there are several regressions in code size in addition to improvements. It would be useful to get measurements from larger code bases.<u></u><u></u></p>
</div></div></div></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br></div>