<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 2:02 PM, Yin Ma <span dir="ltr"><<a href="mailto:yinma@codeaurora.org" target="_blank">yinma@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I understand iteratively applying inliner and other opts until converging or hit cut off<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">may get better results. But indeed, it is very expensive.</span></p></blockquote><div><br></div><div>
The current LLVM inliner *is* such an iterative framework...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> For the application, such as<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">chromium you mentioned, it may take hours to finish one round of compilation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We can have the complete iterative framework but 1 or 2 rounds may be a good<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">heuristic as the default setup.</span></p></blockquote><div><br></div><div>In the past when working on LLVM's existing iterative inlining framework we needed many more rounds. The current system is designed to be iterative while remaining efficient.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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">I also know a little of chromium, in my opinion, having the iterative framework is not <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">enough to bring up the performance because the critical path usually only touch a very<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">small portion of the whole code and hot functions spread in many files. In order to<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">ensure a certain cluster of functions to be inlined, we have to increase threshold to make<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">sure all functions get inlined. As the result, the total size become much larger. So profile<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">guided inlining should do better job here.</span></p></blockquote><div><br></div><div>I'm not sure what you're trying to say here, but note that Chromium is only one C++ project and I'm not sure it is even representative (it may be, I just don't know). I usually look at a pretty wide range of C++ code bases and patterns when considering something like the inliner, ranging from the size of LLVM up to large C++ servers that contain many times the amount of code Chromium does.</div>
<div><br></div><div>It is certainly not my experience that we have to increase thresholds to make sure all functions get inlined for performance. It is more often that *not* inlining cold functions is the key to performance, but even that is a gross oversimplification.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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">And for chromium, top-down approach should do better job than the current bottom up<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Approach especially with –Os option. There are so many C++ function calls. Because <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">CallPenalty in the current SCC inliner is 25 and the threshold of –Os is very low, once a<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Function has one or two call to other function, the inlining will stop. This will leave a lot<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">of functions not get inlined. And a lot of leaf functions are not hot functions. Bottom up<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">approach can do better job for chromium.</span></p></blockquote></div><br>This paragraph seems to contradict its first sentence. Certainly, the reason why I am a strong proponent of bottom-up inlining is due to the nature of call graphs formed by C++ code and its ability to optimize those graphs in an efficient and effective manner.</div>
</div>