[llvm-dev] [RFC] Enable Partial Inliner by default
Tobias Grosser via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 14 16:17:33 PST 2017
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)
More information about the llvm-dev
mailing list