[Bug driver/114531] New: Feature proposal for an `-finline-functions-aggressive` compiler option

[Bug driver/114531] New: Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

            Bug ID: 114531
           Summary: Feature proposal for an
                    `-finline-functions-aggressive` compiler option
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rvmallad at amazon dot com
                CC: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57837&action=edit
patch to implement -finline-functions-aggressive option in GCC

This is a proposal for a user-visible GCC compiler option for aggressive
inlining that is currently only available at -O3 as internal inline parameters
(--param=early-inlining-insns=14 --param=inline-heuristics-hint-percent=600
--param=inline-min-speedup=15 --param=max-inline-insns-auto=30
--param=max-inline-insns-single=200).

I got some perf data for Envoy (https://github.com/envoyproxy/envoy) and SPEC
CPU2017 intrate benchmarks on C7g.2xlarge w Ubuntu22 + gcc-11.4.0. We see perf
gains (2% - 5%) using these aggressive inline parameters (at -O2). Attached is
a patch for this change.

We do not want to add these inline limits at ‘-O2’ itself, as we see from one
of the SPEC CPU tests that got slower. Also, more inline tuning at -O2 would
make some of the symbols not to be available for probe/ debug (that are
available when not using these aggressive inline params).

-----------------------------------------------------------------------
Envoy load_balancer_benchmark – using only 1 CPU – Iterations, higher better
$ bazel run -c opt //test/common/upstream:load_balancer_benchmark

bazel-envoy/external/local_config_cc/BUILD can be changed for adding inline
parameters/ options.

------------------------------------------------------------------------
Benchmark Iterations           Baseline O2        + Inline Params   Gain
------------------------------------------------------------------------
benchmarkRoundRobinLoad          1518               1596           1.05x
BalancerBuild/500/50/50

benchmarkLeastRequestLoad        1465               1514           1.03x
BalancerChooseHost/100/3/1000           

benchmarkRingHashLoadBalancer      33                 34           1.03x
ChooseHost/100/65536/100000           

benchmarkMaglevLoadBalancer        69                 72           1.04x
Weighted/500/95/75/25/10000
------------------------------------------------------------------------

copies=8        "-O2"   "-Ofast" Gain          "-O2 +           Gain w
                                 w Ofast        inlining"       inlining
500.perlbench_r 36.5    34.3     94.0%          34.4            94.2%
502.gcc_r       45.4    47.6     104.8%         47.5            104.6%
505.mcf_r       44.6    48.2     108.1%         44.3            99.3%
520.omnetpp_r   22.1    24.9     112.7%         21.9            99.1%
523.xalancbmk_r 43.8    46.3     105.7%         45.4            103.7%
525.x264_r      44.3    89       200.9%         43.8            98.9%
531.deepsjeng_r 36      37.3     103.6%         37.5            104.2%
541.leela_r     33.5    33.9     101.2%         34.2            102.1%
548.exchange2_r 65.4    76.6     117.1%         65.3            99.8%
557.xz_r        19.8    19.9     100.5%         19.9            100.5%
SPECrate..base  37.1    41.6     112.1%         37.3            100.5%
-----------------------------------------------------------------------

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe we should figure out why the increase of the limits help and add extra
code to get better heuristics rather than just tweaking the limits.

I know that there was some improvements for gcc 14 already for the heuristics
for c++ code.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect the implementation of the option should be changed slight as how does
it interact with the user supplying the params too.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also do you have numbers with lto enabled? Or is these without lto?

Does LTO improve the situation for Envoy too?

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #4 from Rama Malladi <rvmallad at amazon dot com> ---
(In reply to Andrew Pinski from comment #1)
> Maybe we should figure out why the increase of the limits help and add extra
> code to get better heuristics rather than just tweaking the limits.
> 
> I know that there was some improvements for gcc 14 already for the
> heuristics for c++ code.

interesting... thank you.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #5 from Rama Malladi <rvmallad at amazon dot com> ---
(In reply to Andrew Pinski from comment #3)
> Also do you have numbers with lto enabled? Or is these without lto?
> 
> Does LTO improve the situation for Envoy too?

These numbers are without lto. I haven't tried it but I can try and post an
update.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=109849

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See PR 109849 for some of the improvements

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #7 from Rama Malladi <rvmallad at amazon dot com> ---
(In reply to Rama Malladi from comment #5)
> (In reply to Andrew Pinski from comment #3)
> > Also do you have numbers with lto enabled? Or is these without lto?
> > 
> > Does LTO improve the situation for Envoy too?
> 
> These numbers are without lto. I haven't tried it but I can try and post an
> update.

I checked and found the Envoy run was w/o LTO but SPEC cpu2017 intrate was w
LTO.

I tried a build of Envoy w LTO and it failed. I need to debug that issue
further.

Below are perf results w/o LTO. gcc version 11.4.0 (Ubuntu
11.4.0-1ubuntu1~22.04).

copies=8        -O2     -Ofast  Gain w  -O2 + inlining  Gain w
                noLTO   noLTO   Ofast   noLTO           inlining
500.perlbench_r 33.7    33.3    98.8%   33.2            98.5%
502.gcc_r       45.2    46.9    103.8%  46.3            102.4%
505.mcf_r       44.7    44.3    99.1%   44.6            99.8%
520.omnetpp_r   21.4    24.4    114.0%  21.3            99.5%
523.xalancbmk_r 41.6    45.5    109.4%  44              105.8%
525.x264_r      44.2    89      201.4%  43.9            99.3%
531.deepsjeng_r 32.8    32.8    100.0%  33.1            100.9%
541.leela_r     28.6    30.5    106.6%  30.3            105.9%
548.exchange2_r 64.1    64.6    100.8%  64.1            100.0%
557.xz_r        20.3    20.4    100.5%  20.3            100.0%
SPECrate..base  35.6    39.4    110.7%  36              101.1%

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

Rama Malladi <rvmallad at amazon dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rvmallad at amazon dot com

--- Comment #8 from Rama Malladi <rvmallad at amazon dot com> ---
Created attachment 57898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57898&action=edit
Updated patch for `-finline-functions-aggressive` GCC option.

This is an updated patch to include a new GCC option:
`-finline-functions-aggressive`. It has the `-O3` inlining heuristics replaced
with an entry that implies `OPT_finline_functions_aggressive` is enabled. It
also has an entry in `invoke.texi` for documentation stating that this option
selects the same inlining heuristics as `-O3`.

[Bug ipa/114531] Feature proposal for an `-finline-functions-aggressive` compiler option

[rvmallad at amazon dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531

--- Comment #9 from Rama Malladi <rvmallad at amazon dot com> ---
I wanted us to review this feature implementation given GCC 15 Stage 1
development has started. Thank you.