<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 9:21 AM, Adrian Prantl via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Forgot to add that all experiments were done with '-O3 -m64 -fexperimental-new-pass-manage<wbr>r'.<br>
><br>
> Graham Yiu<br>
> LLVM Compiler Development<br>
> IBM Toronto Software Lab<br>
> Office: <a href="tel:%28905%29%20413-4077" value="+19054134077" target="_blank">(905) 413-4077</a> C2-707/8200/Markham<br>
> Email: <a href="mailto:gyiu@ca.ibm.com" target="_blank">gyiu@ca.ibm.com</a><br>
><br>
</span>> <graycol.gif>Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.<br>
<span>><br>
> From: Graham Yiu/Toronto/IBM<br>
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Cc: <a href="mailto:junbuml@codeaurora.org" target="_blank">junbuml@codeaurora.org</a>, <a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a><br>
> Date: 11/02/2017 05:26 PM<br>
> Subject: [RFC] Enable Partial Inliner by default<br>
><br>
><br>
><br>
</span><span>> Hello,<br>
><br>
> I'd like to propose turning on the partial inliner (-enable-partial-inlining) by default.<br>
><br>
> We've seen small gains on SPEC2006/2017 runtimes as well as lnt compile-times with a 2nd stage bootstrap of LLVM. We also saw positive gains on our internal workloads.<br>
><br>
> ------------------------------<wbr>-------<br>
> Brief description of Partial Inlining<br>
> ------------------------------<wbr>-------<br>
> A pass in opt that runs after the normal inlining pass. Looks for branches to a return block in the entry and immediate successor blocks of a function. If found, it outlines the rest of the function using the CodeExtractor.<br>
<br>
</span>Since you mention outlining of code: Does this negatively affect the debug info quality?<br>
<br>
-- adrian<br></blockquote><div><br></div><div>It's not merging anything together so line information is always preserved. For dbg.declare/dbg.addr intrinsics it depends on if the allocas are shrinkwrapped into the outlined function, otherwise the addr is replaced with "metadata !{}". I'm not entirely sure on how dbg.value looks off the top of my head. I haven't actually debugged partial-inlined code so I can't say anything about loss of context from the outlining but those are some observations from the code itself.</div><div><br></div><div>-- River Riddle</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_2860402560042264957m_2709098730001080678HOEnZb"><div class="m_2860402560042264957m_2709098730001080678h5"><br>
<br>
> It then attempts to inline the leftover entry block (and possibly one or more of its successors) to all its callers. This effectively peels the early return block(s) into the caller, which could be executed without incurring the call overhead of the function just to return immediately. Inlining and call overhead cost, as well as branch probabilities of the return block(s) are taken into account before inlining is done. If inlining is not successful, then the changes are discarded.<br>
><br>
> eg.<br>
><br>
> void foo() {<br>
> bar();<br>
> // rest of the code in foo<br>
> }<br>
><br>
> void bar() {<br>
> if (X)<br>
> return;<br>
> // rest of code (to be outlined)<br>
> }<br>
><br>
> After Partial Inlining:<br>
><br>
> void foo() {<br>
> if (!X)<br>
> bar.outlined();<br>
> // rest of the code in foo<br>
> }<br>
><br>
> void bar.outlined() {<br>
> // rest of the code in bar<br>
> }<br>
><br>
><br>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode<br>
><br>
> ------------------------------<wbr>----------------<br>
> Runtime performance (speed)<br>
> ------------------------------<wbr>----------------<br>
> Workload Improvement<br>
> -------- -----------<br>
> SPEC2006(C/C++) 0.06% (geomean)<br>
> SPEC2017(C/C++) 0.10% (geomean)<br>
> ------------------------------<wbr>----------------<br>
> Compile time performance for Bootstrapped LLVM<br>
> ------------------------------<wbr>----------------<br>
> Workload Improvement<br>
> -------- -----------<br>
> SPEC2006(C/C++) 0.41% (cumulative)<br>
> SPEC2017(C/C++) -0.16% (cumulative)<br>
> lnt 0.61% (geomean)<br>
> ------------------------------<wbr>----------------<br>
> Compile time performance<br>
> ------------------------------<wbr>----------------<br>
> Workload Increase<br>
> -------- --------<br>
> SPEC2006(C/C++) 1.31% (cumulative)<br>
> SPEC2017(C/C++) 0.25% (cumulative)<br>
> ------------------------------<wbr>----------------<br>
> Code size<br>
> ------------------------------<wbr>----------------<br>
> Workload Increase<br>
> -------- --------<br>
> SPEC2006(C/C++) 3.90% (geomean)<br>
> SPEC2017(C/C++) 1.05% (geomean)<br>
><br>
> NOTE1: Code size increase in SPEC2006 was mainly attributed to benchmark "astar", which increased by 86%. Removing this outlier, we get a more reasonable increase of 0.58%.<br>
><br>
> NOTE2: There is a patch up for review on Phabricator to enhance the partial inliner with the presence of profiling information (<a href="https://reviews.llvm.org/D38190" rel="noreferrer" target="_blank">https://reviews.llvm.org/D381<wbr>90</a>).<br>
><br>
><br>
> Graham Yiu<br>
> LLVM Compiler Development<br>
> IBM Toronto Software Lab<br>
> Office: <a href="tel:%28905%29%20413-4077" value="+19054134077" target="_blank">(905) 413-4077</a> C2-707/8200/Markham<br>
> Email: <a href="mailto:gyiu@ca.ibm.com" target="_blank">gyiu@ca.ibm.com</a><br>
><br>
><br>
</div></div><div class="m_2860402560042264957m_2709098730001080678HOEnZb"><div class="m_2860402560042264957m_2709098730001080678h5">> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>