Graham Yiu via llvm-dev
2017-Nov-02 22:50 UTC
[llvm-dev] [RFC] Enable Partial Inliner by default
Hi Evgeny,
Ah, yes, I guess I wasn't clear in my original email. I am proposing to
enable it by default on both the new and current pass managers. However, I
didn't collect any data for the current pass manager, since I'm assuming
(hoping) the new pass manager will be the new default at some point in the
future.
I don't think the partial inliner is enabled by default on the new pass
manager (unless something changed recently). I do know it requires a
slightly different option to enable (-enable-npm-partial-inlining).
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: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Graham Yiu <gyiu at ca.ibm.com>
Cc: "junbuml at codeaurora.org" <junbuml at codeaurora.org>,
"llvm-dev at lists.llvm.org" <llvm-dev at
lists.llvm.org>, nd
<nd at arm.com>
Date: 11/02/2017 06:19 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
Hi Graham,
Is your RFC to enable it with the current pass manager? If so, do you have
benchmark data for it?
Am I correct the new pass manager turns the partial inliner by default?
Thanks,
Evgeny Astigeevich
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Graham
Yiu
via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Graham Yiu <gyiu at ca.ibm.com>
Date: Thursday, 2 November 2017 at 22:05
To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Cc: "junbuml at codeaurora.org" <junbuml at codeaurora.org>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
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
Inactive hide details for Graham Yiu---11/02/2017 05:26:58 PM---Hello, I'd
like to propose turning on the partial inliner (-enaGraham 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. 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://reviews.llvm.org/D38190).
Graham Yiu
LLVM Compiler Development
IBM Toronto Software Lab
Office: (905) 413-4077 C2-707/8200/Markham
Email: gyiu at ca.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171102/fd92f984/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/20171102/fd92f984/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17218755.gif
Type: image/gif
Size: 106 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171102/fd92f984/attachment-0001.gif>