[llvm-dev] [RFC] Enable Partial Inliner by default

[Graham Yiu via llvm-dev]

Hi Adrian,

As far as I know, the code extractor takes care of fixing up the debug
information, if necessary.  However, I haven't verified this myself and to
be honest my knowledge of how debug information is represented in LLVM is
limited.

Cheers,

Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077      C2-707/8200/Markham
Email: gyiu at ca.ibm.com



From:	Adrian Prantl <aprantl at apple.com>
To:	Graham Yiu <gyiu at ca.ibm.com>
Cc:	llvm-dev at lists.llvm.org, junbuml at codeaurora.org
Date:	11/03/2017 12:21 PM
Subject:	Re: [llvm-dev] [RFC] Enable Partial Inliner by default
Sent by:	aprantl at apple.com





> On Nov 2, 2017, at 3:05 PM, Graham Yiu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Forgot to add that all experiments were done with '-O3 -m64
-fexperimental-new-pass-manager'.
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077 C2-707/8200/Markham
> Email: gyiu at ca.ibm.com
>
> <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.
>
> From: Graham Yiu/Toronto/IBM
> To: llvm-dev at lists.llvm.org
> Cc: junbuml at codeaurora.org, xinliangli at gmail.com
> Date: 11/02/2017 05:26 PM
> Subject: [RFC] Enable Partial Inliner by default
>
>
>
> Hello,
>
> I'd like to propose turning on the partial inliner
(-enable-partial-inlining) by default.
>
> 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.
>
> -------------------------------------
> Brief description of Partial Inlining
> -------------------------------------
> 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.

Since you mention outlining of code: Does this negatively affect the debug
info quality?

-- adrian


> 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.
>
> eg.
>
> void foo() {
> bar();
> // rest of the code in foo
> }
>
> void bar() {
> if (X)
> return;
> // rest of code (to be outlined)
> }
>
> After Partial Inlining:
>
> void foo() {
> if (!X)
> bar.outlined();
> // rest of the code in foo
> }
>
> void bar.outlined() {
> // rest of the code in bar
> }
>
>
> Here are the numbers on a Power8 PPCLE running Ubuntu 15.04 in ST-mode
>
> ----------------------------------------------
> Runtime performance (speed)
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.06% (geomean)
> SPEC2017(C/C++) 0.10% (geomean)
> ----------------------------------------------
> Compile time performance for Bootstrapped LLVM
> ----------------------------------------------
> Workload Improvement
> -------- -----------
> SPEC2006(C/C++) 0.41% (cumulative)
> SPEC2017(C/C++) -0.16% (cumulative)
> lnt 0.61% (geomean)
> ----------------------------------------------
> Compile time performance
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 1.31% (cumulative)
> SPEC2017(C/C++) 0.25% (cumulative)
> ----------------------------------------------
> Code size
> ----------------------------------------------
> Workload Increase
> -------- --------
> SPEC2006(C/C++) 3.90% (geomean)
> SPEC2017(C/C++) 1.05% (geomean)
>
> 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%.
>
> NOTE2: There is a patch up for review on Phabricator to enhance the
partial inliner with the presence of profiling information (
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=vHBrl23Udp8MJ7l9cceP-oY_G3_H42oc7IuMFbx90_Y&s=Hzu_t0oXe3-l5xEwxx6s4eBMb6oKEGsi1vxFkqGHlaI&e=
).
>
>
> Graham Yiu
> LLVM Compiler Development
> IBM Toronto Software Lab
> Office: (905) 413-4077 C2-707/8200/Markham
> Email: gyiu at ca.ibm.com
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=vHBrl23Udp8MJ7l9cceP-oY_G3_H42oc7IuMFbx90_Y&s=pjIBJMaH7s_RCLdln5Z-pyBGmlqXE43Ch0Rh6GnY9oU&e=




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171103/448210f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171103/448210f6/attachment.gif>