thr3ads.net - llvm dev - [llvm-dev] [RFC] Enable Partial Inliner by default [Nov 2017]

If this information is useful, please help other people find it:
Share via:

Evgeny Astigeevich via llvm-dev

2017-Nov-10 21:28 UTC

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

Hi Graham,

Thank you for offering help. I am trying to create a reproducer. The problem is
that the crashes happen whilst LTO is used. One thing I am sure about IR is
broken at compile time.

Thanks,
Evgeny

From: Graham Yiu <gyiu at ca.ibm.com>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

I just realized that if these are compile-time errors I can help investigate on
my end. Do you have something I can use to reproduce?

Cheers,

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/08/2017 06:00:05 PM---Thanks, Evgeny.
Let me know if there's something in the partial]Graham Yiu---11/08/2017
06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the
partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________


Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is
causing the issue(s) you're seeing.

Cheers,

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 Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi
Graham, I’ve almost finished my runs. However I’v]Evgeny Astigeevich
---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However
I’ve got couple compiler crashes:

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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>, nd <nd at arm.com>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________



Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function
…
LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <gyiu at ca.ibm.com>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete?
We're looking to turn this on sooner rather than later, if there aren't
objections from folks running on other platforms.

Cheers,

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/03/2017 12:40:10 PM---Hi Evgeny, Yes,
please do.  It was our hope that folks would ve]Graham Yiu---11/03/2017 12:40:10
PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the
impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________



Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the
partial inliner on the platforms they're currently working on.

Cheers,

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 Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi,
We'd like to check impact on armv7m and armv6m tar]Evgeny Astigeevich
---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and
armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________




Hi,



We'd like to check impact on armv7m and armv6m targets, especially code
size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias
Grosser via llvm-dev <llvm-dev at lists.llvm.org>

Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <gyiu at ca.ibm.com>, "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



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
> Email had 1 attachment:
> + graycol.gif
> 1k (image/gif)
_______________________________________________

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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e














-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/81b992cc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 106 bytes
Desc: image001.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/81b992cc/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 107 bytes
Desc: image002.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/81b992cc/attachment-0001.gif>

Evgeny Astigeevich via llvm-dev

2017-Nov-11 17:21 UTC

head link

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

Hi Graham,

I’ve got results of benchmarking. Armv7m and armv6m are not affected. No changes
in scores nor code sizes.
I did some additional benchmarks runs for AArch64 and AArch32.

LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
MultiSource/Applications/aha/aha                          6.73% execution time
regression
MultiSource/Applications/sqlite3/sqlite3              2.61% execution time
improvement

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan            
27.07%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                           
16.54%
MultiSource/Benchmarks/Olden/bh/bh                                              
10.11%
MultiSource/Benchmarks/McCat/18-imp/imp                                         
8.38%
SingleSource/Benchmarks/Misc-C++/Large/ray                                      
6.54%
MultiSource/Benchmarks/Prolangs-C/bison/mybison                                 
5.92%
MultiSource/Benchmarks/MallocBench/espresso/espresso                            
5.09%
-------------------------------------------------------------------------------------------------------------------------

LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57 -fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
No significant performance improvements/regressions.

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan            
24.51%
MultiSource/Benchmarks/McCat/18-imp/imp                                         
12.99%
MultiSource/Benchmarks/McCat/08-main/main Profile                               
8.63%
MultiSource/Benchmarks/Olden/bh/bh                                              
8.30%
SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash                          
7.43%
SingleSource/Benchmarks/Misc-C++/bigfib                                         
6.24%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                           
6.10%
MultiSource/Benchmarks/Prolangs-C/agrep/agrep                                   
5.65%
MultiSource/Benchmarks/Ptrdist/yacr2/yacr2                                      
5.01%
-------------------------------------------------------------------------------------------------------------------------

It can be seen there are the same benchmarks have code size regressed. Are they
known?
I am still trying to figure out what is wrong with the debug info.

Thanks,
Evgeny Astigeevich


From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Friday, 10 November 2017 at 21:28
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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

Thank you for offering help. I am trying to create a reproducer. The problem is
that the crashes happen whilst LTO is used. One thing I am sure about IR is
broken at compile time.

Thanks,
Evgeny

From: Graham Yiu <gyiu at ca.ibm.com>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

I just realized that if these are compile-time errors I can help investigate on
my end. Do you have something I can use to reproduce?

Cheers,

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/08/2017 06:00:05 PM---Thanks, Evgeny.
Let me know if there's something in the partial]Graham Yiu---11/08/2017
06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the
partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________


Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is
causing the issue(s) you're seeing.

Cheers,

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 Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi
Graham, I’ve almost finished my runs. However I’v]Evgeny Astigeevich
---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However
I’ve got couple compiler crashes:

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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>, nd <nd at arm.com>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________



Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function
…
LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <gyiu at ca.ibm.com>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete?
We're looking to turn this on sooner rather than later, if there aren't
objections from folks running on other platforms.

Cheers,

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/03/2017 12:40:10 PM---Hi Evgeny, Yes,
please do.  It was our hope that folks would ve]Graham Yiu---11/03/2017 12:40:10
PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the
impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________



Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the
partial inliner on the platforms they're currently working on.

Cheers,

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 Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi,
We'd like to check impact on armv7m and armv6m tar]Evgeny Astigeevich
---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and
armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________




Hi,



We'd like to check impact on armv7m and armv6m targets, especially code
size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias
Grosser via llvm-dev <llvm-dev at lists.llvm.org>

Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <gyiu at ca.ibm.com>, "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



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
> Email had 1 attachment:
> + graycol.gif
> 1k (image/gif)
_______________________________________________

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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e















-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171111/b03d2eb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 107 bytes
Desc: image001.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171111/b03d2eb8/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 108 bytes
Desc: image002.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171111/b03d2eb8/attachment-0001.gif>

Evgeny Astigeevich via llvm-dev

2017-Nov-13 14:47 UTC

head link

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

Hi Graham,

I created a bug report with a reproducer for the failures I’ve got:
https://bugs.llvm.org/show_bug.cgi?id=35288
I have also found that LTO reverts everything the partial inliner has done.
Maybe the partial inliner should not be used at the first LTO phase
(compilation).

I hope I’ll have a chance to look at the code size regressions this week.

Thanks,
Evgeny Astigeevich

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Evgeny
Astigeevich via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Saturday, 11 November 2017 at 17:21
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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>, nd <nd at arm.com>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

I’ve got results of benchmarking. Armv7m and armv6m are not affected. No changes
in scores nor code sizes.
I did some additional benchmarks runs for AArch64 and AArch32.

LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
MultiSource/Applications/aha/aha                          6.73% execution time
regression
MultiSource/Applications/sqlite3/sqlite3              2.61% execution time
improvement

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan            
27.07%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                           
16.54%
MultiSource/Benchmarks/Olden/bh/bh                                              
10.11%
MultiSource/Benchmarks/McCat/18-imp/imp                                         
8.38%
SingleSource/Benchmarks/Misc-C++/Large/ray                                      
6.54%
MultiSource/Benchmarks/Prolangs-C/bison/mybison                                 
5.92%
MultiSource/Benchmarks/MallocBench/espresso/espresso                            
5.09%
-------------------------------------------------------------------------------------------------------------------------

LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57 -fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
No significant performance improvements/regressions.

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan            
24.51%
MultiSource/Benchmarks/McCat/18-imp/imp                                         
12.99%
MultiSource/Benchmarks/McCat/08-main/main Profile                               
8.63%
MultiSource/Benchmarks/Olden/bh/bh                                              
8.30%
SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash                          
7.43%
SingleSource/Benchmarks/Misc-C++/bigfib                                         
6.24%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1                           
6.10%
MultiSource/Benchmarks/Prolangs-C/agrep/agrep                                   
5.65%
MultiSource/Benchmarks/Ptrdist/yacr2/yacr2                                      
5.01%
-------------------------------------------------------------------------------------------------------------------------

It can be seen there are the same benchmarks have code size regressed. Are they
known?
I am still trying to figure out what is wrong with the debug info.

Thanks,
Evgeny Astigeevich


From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Friday, 10 November 2017 at 21:28
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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

Thank you for offering help. I am trying to create a reproducer. The problem is
that the crashes happen whilst LTO is used. One thing I am sure about IR is
broken at compile time.

Thanks,
Evgeny

From: Graham Yiu <gyiu at ca.ibm.com>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

I just realized that if these are compile-time errors I can help investigate on
my end. Do you have something I can use to reproduce?

Cheers,

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/08/2017 06:00:05 PM---Thanks, Evgeny.
Let me know if there's something in the partial]Graham Yiu---11/08/2017
06:00:05 PM---Thanks, Evgeny. Let me know if there's something in the
partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________


Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is
causing the issue(s) you're seeing.

Cheers,

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 Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi
Graham, I’ve almost finished my runs. However I’v]Evgeny Astigeevich
---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs. However
I’ve got couple compiler crashes:

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>, "Tobias Grosser" <tobias.grosser at
inf.ethz.ch>, nd <nd at arm.com>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________



Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function
…
LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <gyiu at ca.ibm.com>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be complete?
We're looking to turn this on sooner rather than later, if there aren't
objections from folks running on other platforms.

Cheers,

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/03/2017 12:40:10 PM---Hi Evgeny, Yes,
please do.  It was our hope that folks would ve]Graham Yiu---11/03/2017 12:40:10
PM---Hi Evgeny, Yes, please do. It was our hope that folks would verify the
impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at inf.ethz.ch>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

________________________________



Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the
partial inliner on the platforms they're currently working on.

Cheers,

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 Evgeny Astigeevich ---11/03/2017 12:18:05 PM---Hi,
We'd like to check impact on armv7m and armv6m tar]Evgeny Astigeevich
---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on armv7m and
armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
________________________________




Hi,



We'd like to check impact on armv7m and armv6m targets, especially code
size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias
Grosser via llvm-dev <llvm-dev at lists.llvm.org>

Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <gyiu at ca.ibm.com>, "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



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
> Email had 1 attachment:
> + graycol.gif
> 1k (image/gif)
_______________________________________________

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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
















-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/8a199d1c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 108 bytes
Desc: image001.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/8a199d1c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 109 bytes
Desc: image002.gif
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171113/8a199d1c/attachment-0001.gif>

Graham Yiu via llvm-dev

2017-Nov-14 21:40 UTC

head link

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

Hi Evgeny,

I agree that we probably need to tweak when the partial inliner should run
when using LTO/thinLTO.  The easiest thing to do is likely to just disable
partial inlining in the pre-LTO pass during compilation, so we don't
outline things that the LTO inliner will eventually inline again.

As for the code size increases you're seeing, it's not too surprising,
though it would've been nice to see some performance speed-ups.  Do you
know if we just happen to increase the size of functions that are
infrequently executed?

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>, Tobias
            Grosser <tobias.grosser at inf.ethz.ch>, nd <nd at
arm.com>
Date:	11/13/2017 09:47 AM
Subject:	Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,

I created a bug report with a reproducer for the failures I’ve got:
https://bugs.llvm.org/show_bug.cgi?id=35288
I have also found that LTO reverts everything the partial inliner has done.
Maybe the partial inliner should not be used at the first LTO phase
(compilation).

I hope I’ll have a chance to look at the code size regressions this week.

Thanks,
Evgeny Astigeevich

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Evgeny
Astigeevich via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Saturday, 11 November 2017 at 17:21
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>,
Tobias Grosser
<tobias.grosser at inf.ethz.ch>, nd <nd at arm.com>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

I’ve got results of benchmarking. Armv7m and armv6m are not affected. No
changes in scores nor code sizes.
I did some additional benchmarks runs for AArch64 and AArch32.

LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
MultiSource/Applications/aha/aha                          6.73% execution
time regression
MultiSource/Applications/sqlite3/sqlite3              2.61% execution time
improvement

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
27.07%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
16.54%
MultiSource/Benchmarks/Olden/bh/bh
10.11%
MultiSource/Benchmarks/McCat/18-imp/imp
8.38%
SingleSource/Benchmarks/Misc-C++/Large/ray
6.54%
MultiSource/Benchmarks/Prolangs-C/bison/mybison
5.92%
MultiSource/Benchmarks/MallocBench/espresso/espresso
5.09%
-------------------------------------------------------------------------------------------------------------------------

LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
No significant performance improvements/regressions.

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
24.51%
MultiSource/Benchmarks/McCat/18-imp/imp
12.99%
MultiSource/Benchmarks/McCat/08-main/main Profile
8.63%
MultiSource/Benchmarks/Olden/bh/bh
8.30%
SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash
7.43%
SingleSource/Benchmarks/Misc-C++/bigfib
6.24%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
6.10%
MultiSource/Benchmarks/Prolangs-C/agrep/agrep
5.65%
MultiSource/Benchmarks/Ptrdist/yacr2/yacr2
5.01%
-------------------------------------------------------------------------------------------------------------------------

It can be seen there are the same benchmarks have code size regressed. Are
they known?
I am still trying to figure out what is wrong with the debug info.

Thanks,
Evgeny Astigeevich


From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Friday, 10 November 2017 at 21:28
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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

Thank you for offering help. I am trying to create a reproducer. The
problem is that the crashes happen whilst LTO is used. One thing I am sure
about IR is broken at compile time.

Thanks,
Evgeny

From: Graham Yiu <gyiu at ca.ibm.com>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Evgeny,

I just realized that if these are compile-time errors I can help
investigate on my end. Do you have something I can use to reproduce?

Cheers,

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/08/2017 06:00:05 PM---Thanks,
Evgeny. Let me know if there's something in the partialGraham
Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's
something in the partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
"Tobias Grosser" <tobias.grosser at inf.ethz.ch>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is
causing the issue(s) you're seeing.

Cheers,

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 Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi
Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich
---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs.
However I’ve got couple compiler crashes:

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>,
"Tobias Grosser" <tobias.grosser at inf.ethz.ch>, nd <nd at
arm.com>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function
…
LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <gyiu at ca.ibm.com>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be
complete? We're looking to turn this on sooner rather than later, if there
aren't objections from folks running on other platforms.

Cheers,

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/03/2017 12:40:10 PM---Hi Evgeny,
Yes, please do.  It was our hope that folks would veGraham Yiu---11/03/2017
12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would
verify the impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the
partial inliner on the platforms they're currently working on.

Cheers,

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 Evgeny Astigeevich ---11/03/2017 12:18:05
PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny
Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on
armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code
size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias
Grosser via llvm-dev <llvm-dev at lists.llvm.org>

Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <gyiu at ca.ibm.com>, "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



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
> Email had 1 attachment:
> + graycol.gif
> 1k (image/gif)
_______________________________________________

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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e


















-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171114/6c239bda/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/20171114/6c239bda/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 78719646.gif
Type: image/gif
Size: 108 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171114/6c239bda/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 78607350.gif
Type: image/gif
Size: 109 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171114/6c239bda/attachment-0002.gif>

Tobias Grosser via llvm-dev

2017-Nov-15 00:17 UTC

head link

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

On Tue, Nov 14, 2017, at 22:40, Graham Yiu via llvm-dev
wrote:> Hi Evgeny,
> 
> I agree that we probably need to tweak when the partial inliner should
> run
> when using LTO/thinLTO.  The easiest thing to do is likely to just
> disable
> partial inlining in the pre-LTO pass during compilation, so we don't
> outline things that the LTO inliner will eventually inline again.
> 
> As for the code size increases you're seeing, it's not too
surprising,
> though it would've been nice to see some performance speed-ups.  Do you
> know if we just happen to increase the size of functions that are
> infrequently executed?
Yes, disabling the partial inliner in the pre-LTO phase is likely the
right choice. Would be great to get a patch that implements this in.

Best,
Tobias
> 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>, Tobias
>             Grosser <tobias.grosser at inf.ethz.ch>, nd <nd at
arm.com>
> Date:   11/13/2017 09:47 AM
> Subject:        Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> Hi Graham,
> 
> I created a bug report with a reproducer for the failures I’ve got:
> https://bugs.llvm.org/show_bug.cgi?id=35288
> I have also found that LTO reverts everything the partial inliner has
> done.
> Maybe the partial inliner should not be used at the first LTO phase
> (compilation).
> 
> I hope I’ll have a chance to look at the code size regressions this week.
> 
> Thanks,
> Evgeny Astigeevich
> 
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Evgeny
> Astigeevich via llvm-dev <llvm-dev at lists.llvm.org>
> Reply-To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> Date: Saturday, 11 November 2017 at 17:21
> 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>,
Tobias Grosser
> <tobias.grosser at inf.ethz.ch>, nd <nd at arm.com>
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> Hi Graham,
> 
> I’ve got results of benchmarking. Armv7m and armv6m are not affected. No
> changes in scores nor code sizes.
> I did some additional benchmarks runs for AArch64 and AArch32.
> 
> LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb
> -fomit-frame-pointer
>
-------------------------------------------------------------------------------------------------------------------------
> MultiSource/Applications/aha/aha                          6.73% execution
> time regression
> MultiSource/Applications/sqlite3/sqlite3              2.61% execution
> time
> improvement
> 
> Code size regressions greater than 5%:
> MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
> 27.07%
> MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
> 16.54%
> MultiSource/Benchmarks/Olden/bh/bh
> 10.11%
> MultiSource/Benchmarks/McCat/18-imp/imp
> 8.38%
> SingleSource/Benchmarks/Misc-C++/Large/ray
> 6.54%
> MultiSource/Benchmarks/Prolangs-C/bison/mybison
> 5.92%
> MultiSource/Benchmarks/MallocBench/espresso/espresso
> 5.09%
>
-------------------------------------------------------------------------------------------------------------------------
> 
> LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57
> -fomit-frame-pointer
>
-------------------------------------------------------------------------------------------------------------------------
> No significant performance improvements/regressions.
> 
> Code size regressions greater than 5%:
> MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
> 24.51%
> MultiSource/Benchmarks/McCat/18-imp/imp
> 12.99%
> MultiSource/Benchmarks/McCat/08-main/main Profile
> 8.63%
> MultiSource/Benchmarks/Olden/bh/bh
> 8.30%
> SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash
> 7.43%
> SingleSource/Benchmarks/Misc-C++/bigfib
> 6.24%
> MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
> 6.10%
> MultiSource/Benchmarks/Prolangs-C/agrep/agrep
> 5.65%
> MultiSource/Benchmarks/Ptrdist/yacr2/yacr2
> 5.01%
>
-------------------------------------------------------------------------------------------------------------------------
> 
> It can be seen there are the same benchmarks have code size regressed.
> Are
> they known?
> I am still trying to figure out what is wrong with the debug info.
> 
> Thanks,
> Evgeny Astigeevich
> 
> 
> From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> Date: Friday, 10 November 2017 at 21:28
> 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>,
> Tobias Grosser <tobias.grosser at inf.ethz.ch>
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> Hi Graham,
> 
> Thank you for offering help. I am trying to create a reproducer. The
> problem is that the crashes happen whilst LTO is used. One thing I am
> sure
> about IR is broken at compile time.
> 
> Thanks,
> Evgeny
> 
> From: Graham Yiu <gyiu at ca.ibm.com>
> Date: Friday, 10 November 2017 at 16:09
> To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
> Tobias Grosser <tobias.grosser at inf.ethz.ch>
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> Hi Evgeny,
> 
> I just realized that if these are compile-time errors I can help
> investigate on my end. Do you have something I can use to reproduce?
> 
> Cheers,
> 
> 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/08/2017 06:00:05 PM---Thanks,
> Evgeny. Let me know if there's something in the partialGraham
> Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's
> something in the partial inlining code that is causing the is
> 
> From: Graham Yiu/Toronto/IBM
> To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
> "Tobias Grosser" <tobias.grosser at inf.ethz.ch>
> Date: 11/08/2017 06:00 PM
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> Thanks, Evgeny.
> 
> Let me know if there's something in the partial inlining code that is
> causing the issue(s) you're seeing.
> 
> Cheers,
> 
> 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 Evgeny Astigeevich ---11/08/2017 05:13:09
> PM---Hi
> Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich
> ---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs.
> However I’ve got couple compiler crashes:
> 
> 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>,
> "Tobias Grosser" <tobias.grosser at inf.ethz.ch>, nd <nd
at arm.com>
> Date: 11/08/2017 05:13 PM
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> 
> Hi Graham,
> 
> I’ve almost finished my runs. However I’ve got couple compiler crashes:
> 
> !dbg attachment points at wrong subprogram for function
> …
> LLVM ERROR: Broken module found, compilation aborted!
> 
> This will take some time to investigate.
> 
> Thanks,
> Evgeny Astigeevich
> 
> 
> From: Graham Yiu <gyiu at ca.ibm.com>
> Date: Tuesday, 7 November 2017 at 16:19
> To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
> Tobias Grosser <tobias.grosser at inf.ethz.ch>
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> Hi Evgeny,
> 
> When you think the experiments on armv7m and armv6m targets will be
> complete? We're looking to turn this on sooner rather than later, if
> there
> aren't objections from folks running on other platforms.
> 
> Cheers,
> 
> 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/03/2017 12:40:10 PM---Hi
> Evgeny,
> Yes, please do.  It was our hope that folks would veGraham
> Yiu---11/03/2017
> 12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would
> verify the impact of the partial inline
> 
> From: Graham Yiu/Toronto/IBM
> To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
> Tobias Grosser <tobias.grosser at inf.ethz.ch>
> Date: 11/03/2017 12:40 PM
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> 
> Hi Evgeny,
> 
> Yes, please do. It was our hope that folks would verify the impact of the
> partial inliner on the platforms they're currently working on.
> 
> Cheers,
> 
> 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 Evgeny Astigeevich ---11/03/2017 12:18:05
> PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny
> Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact
on
> armv7m and armv6m targets, especially code size. We have not tried
> 
> From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
> Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default
> 
> 
> 
> 
> 
> Hi,
> 
> 
> 
> We'd like to check impact on armv7m and armv6m targets, especially code
> size. We have not tried the partial inliner on them.
> 
> 
> 
> Could a decision to turn it on by default wait for results?
> 
> 
> 
> Thanks,
> 
> Evgeny Astigeevich
> 
> The Arm Compiler Optimization team
> 
> 
> 
> -----Original Message-----
> 
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Tobias
> Grosser via llvm-dev <llvm-dev at lists.llvm.org>
> 
> Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>
> 
> Date: Thursday, 2 November 2017 at 23:32
> 
> To: Graham Yiu <gyiu at ca.ibm.com>, "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
> 
> 
> 
> Hi Graham,
> 
> 
> 
> I think this is a good idea. It is also useful for libquantum, where
> 
> together with some other changes, it enables Polly to perform libfusion.
> 
> 
> 
> The ARM people also played with the partial inliner and might have
> 
> feedback.
> 
> 
> 
> Best,
> 
> Tobias
> 
> 
> 
> On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
> 
> >
> 
> >
> 
> >
> 
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e>
> 
> > Email had 1 attachment:
> 
> > + graycol.gif
> 
> > 1k (image/gif)
> 
> _______________________________________________
> 
> 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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> Email had 3 attachments:
> + graycol.gif
>   1k (image/gif)
> + 78719646.gif
>   1k (image/gif)
> + 78607350.gif
>   1k (image/gif)

Graham Yiu via llvm-dev

2017-Nov-27 18:25 UTC

head link

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

Hello,

I've posted a preliminary patch on Phabricator

https://reviews.llvm.org/D40477

that enables the partial inliner by default and disables the partial
inlining pass during ThinLTO prepare/prelink and leaves it to the actual
ThinLTO pass to do the work.  The regular LTO prepare/prelink pass has been
left alone since ThinLTO has a customized one.

I'll gather some SPEC numbers this week to make sure disabling PI during
ThinLTO prepare/prelink has a positive/neutral impact.

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:	Graham Yiu/Toronto/IBM
To:	Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>, Tobias Grosser <tobias.grosser at
inf.ethz.ch>
Date:	11/14/2017 04:40 PM
Subject:	Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

I agree that we probably need to tweak when the partial inliner should run
when using LTO/thinLTO.  The easiest thing to do is likely to just disable
partial inlining in the pre-LTO pass during compilation, so we don't
outline things that the LTO inliner will eventually inline again.

As for the code size increases you're seeing, it's not too surprising,
though it would've been nice to see some performance speed-ups.  Do you
know if we just happen to increase the size of functions that are
infrequently executed?

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>, Tobias
            Grosser <tobias.grosser at inf.ethz.ch>, nd <nd at
arm.com>
Date:	11/13/2017 09:47 AM
Subject:	Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Graham,

I created a bug report with a reproducer for the failures I’ve got:
https://bugs.llvm.org/show_bug.cgi?id=35288
I have also found that LTO reverts everything the partial inliner has done.
Maybe the partial inliner should not be used at the first LTO phase
(compilation).

I hope I’ll have a chance to look at the code size regressions this week.

Thanks,
Evgeny Astigeevich

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Evgeny
Astigeevich via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Saturday, 11 November 2017 at 17:21
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>,
Tobias Grosser
<tobias.grosser at inf.ethz.ch>, nd <nd at arm.com>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

I’ve got results of benchmarking. Armv7m and armv6m are not affected. No
changes in scores nor code sizes.
I did some additional benchmarks runs for AArch64 and AArch32.

LNT test suite, AArch32, Cortex-A57, -O3 -mcpu=cortex-a57 -mthumb
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
MultiSource/Applications/aha/aha                          6.73% execution
time regression
MultiSource/Applications/sqlite3/sqlite3              2.61% execution time
improvement

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
27.07%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
16.54%
MultiSource/Benchmarks/Olden/bh/bh
10.11%
MultiSource/Benchmarks/McCat/18-imp/imp
8.38%
SingleSource/Benchmarks/Misc-C++/Large/ray
6.54%
MultiSource/Benchmarks/Prolangs-C/bison/mybison
5.92%
MultiSource/Benchmarks/MallocBench/espresso/espresso
5.09%
-------------------------------------------------------------------------------------------------------------------------

LNT test suite, AArch64, Cortex-A57, -O3 -mcpu=cortex-a57
-fomit-frame-pointer
-------------------------------------------------------------------------------------------------------------------------
No significant performance improvements/regressions.

Code size regressions greater than 5%:
MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan
24.51%
MultiSource/Benchmarks/McCat/18-imp/imp
12.99%
MultiSource/Benchmarks/McCat/08-main/main Profile
8.63%
MultiSource/Benchmarks/Olden/bh/bh
8.30%
SingleSource/Benchmarks/Shootout-C++/Shootout-C++-hash
7.43%
SingleSource/Benchmarks/Misc-C++/bigfib
6.24%
MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1
6.10%
MultiSource/Benchmarks/Prolangs-C/agrep/agrep
5.65%
MultiSource/Benchmarks/Ptrdist/yacr2/yacr2
5.01%
-------------------------------------------------------------------------------------------------------------------------

It can be seen there are the same benchmarks have code size regressed. Are
they known?
I am still trying to figure out what is wrong with the debug info.

Thanks,
Evgeny Astigeevich


From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
Date: Friday, 10 November 2017 at 21:28
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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default

Hi Graham,

Thank you for offering help. I am trying to create a reproducer. The
problem is that the crashes happen whilst LTO is used. One thing I am sure
about IR is broken at compile time.

Thanks,
Evgeny

From: Graham Yiu <gyiu at ca.ibm.com>
Date: Friday, 10 November 2017 at 16:09
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Hi Evgeny,

I just realized that if these are compile-time errors I can help
investigate on my end. Do you have something I can use to reproduce?

Cheers,

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/08/2017 06:00:05 PM---Thanks,
Evgeny. Let me know if there's something in the partialGraham
Yiu---11/08/2017 06:00:05 PM---Thanks, Evgeny. Let me know if there's
something in the partial inlining code that is causing the is

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
"Tobias Grosser" <tobias.grosser at inf.ethz.ch>
Date: 11/08/2017 06:00 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default



Thanks, Evgeny.

Let me know if there's something in the partial inlining code that is
causing the issue(s) you're seeing.

Cheers,

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 Evgeny Astigeevich ---11/08/2017 05:13:09 PM---Hi
Graham, I’ve almost finished my runs. However I’vEvgeny Astigeevich
---11/08/2017 05:13:09 PM---Hi Graham, I’ve almost finished my runs.
However I’ve got couple compiler crashes:

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>,
"Tobias Grosser" <tobias.grosser at inf.ethz.ch>, nd <nd at
arm.com>
Date: 11/08/2017 05:13 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Graham,

I’ve almost finished my runs. However I’ve got couple compiler crashes:

!dbg attachment points at wrong subprogram for function
…
LLVM ERROR: Broken module found, compilation aborted!

This will take some time to investigate.

Thanks,
Evgeny Astigeevich


From: Graham Yiu <gyiu at ca.ibm.com>
Date: Tuesday, 7 November 2017 at 16:19
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default


Hi Evgeny,

When you think the experiments on armv7m and armv6m targets will be
complete? We're looking to turn this on sooner rather than later, if there
aren't objections from folks running on other platforms.

Cheers,

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/03/2017 12:40:10 PM---Hi Evgeny,
Yes, please do.  It was our hope that folks would veGraham Yiu---11/03/2017
12:40:10 PM---Hi Evgeny, Yes, please do. It was our hope that folks would
verify the impact of the partial inline

From: Graham Yiu/Toronto/IBM
To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.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>,
Tobias Grosser <tobias.grosser at inf.ethz.ch>
Date: 11/03/2017 12:40 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default




Hi Evgeny,

Yes, please do. It was our hope that folks would verify the impact of the
partial inliner on the platforms they're currently working on.

Cheers,

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 Evgeny Astigeevich ---11/03/2017 12:18:05
PM---Hi, We'd like to check impact on armv7m and armv6m tarEvgeny
Astigeevich ---11/03/2017 12:18:05 PM---Hi, We'd like to check impact on
armv7m and armv6m targets, especially code size. We have not tried

From: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
To: Tobias Grosser <tobias.grosser at inf.ethz.ch>, 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/03/2017 12:18 PM
Subject: Re: [llvm-dev] [RFC] Enable Partial Inliner by default





Hi,



We'd like to check impact on armv7m and armv6m targets, especially code
size. We have not tried the partial inliner on them.



Could a decision to turn it on by default wait for results?



Thanks,

Evgeny Astigeevich

The Arm Compiler Optimization team



-----Original Message-----

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Tobias
Grosser via llvm-dev <llvm-dev at lists.llvm.org>

Reply-To: Tobias Grosser <tobias.grosser at inf.ethz.ch>

Date: Thursday, 2 November 2017 at 23:32

To: Graham Yiu <gyiu at ca.ibm.com>, "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



Hi Graham,



I think this is a good idea. It is also useful for libquantum, where

together with some other changes, it enables Polly to perform libfusion.



The ARM people also played with the partial inliner and might have

feedback.



Best,

Tobias



On Thu, Nov 2, 2017, at 23:05, Graham Yiu via llvm-dev 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
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D38190&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=6o17wydYZM0l4kPAb3l3cJ95JRPoYb-3l4sHv-R0GaA&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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e
> Email had 1 attachment:
> + graycol.gif
> 1k (image/gif)
_______________________________________________

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=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=4ST7e3kMd0GTi3w9ByK5Cw&m=sY89ox2ivgmox5Vg311rAsEr4WFT-o-LRopDU9e7rl0&s=_WAS3iXS9l627yoGcLCkw5IMyoeBRXAb3ShcSIW5qjk&e



















-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171127/782d60b4/attachment-0001.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/20171127/782d60b4/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 69731484.gif
Type: image/gif
Size: 108 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171127/782d60b4/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 69805255.gif
Type: image/gif
Size: 109 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171127/782d60b4/attachment-0005.gif>

Reasonably Related Threads

Search for more apparently analagous threads

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

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

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

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

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

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

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

Reasonably Related Threads