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

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #18 from Jan Hubicka <hubicka at ucw dot cz> ---
> different issue from the one that is raised in the PR.  (Unless we think that
> -O2 and -O3 should always have the same inlining heuristics henceforward, but
> that seems unlikely.)

Yes, I think point of -O3 is to let compiler to be more aggressive than
what seems desirable for your average distro build defaults (which needs
to balance speed and size).
> 
> At the moment, -O3 is essentially -O2 + some -f options + some --param options.
>  Users who want to pick & chose some of the -f options can do so, and can add
> them to stable build systems.  Normally, obsolete -f options are turned into
> no-ops rather than removed.  But users can't pick & choose the --params, and
> add them to stable build systems, because we reserve the right to remove
> --params without warning.

Moreover those --params are slowly chaning their meaning in time.  I
need to retune inliner when early inlining gets smarter.
> 
> So IMO, we should have an -f option that represents “the inlining parameters
> enabled by -O3”, whatever they happen to be for a given release.  It's OK if
> the set is empty.
> 
> For such a change, it doesn't really matter whether the current --params are
> the right ones.  It just matters that the --params are the ones that we
> currently use.  If the --params are changed later, the -f option and -O3 will
> automatically stay in sync.

I am trying to understand how useful this is.  I am basically worried
about two things
 1) we have other optimization passes that behave differently at -O2 and
    -O3 (vectorizer, unrolling etc.) and I think we may want to have
    more. We also have -Os and -O1.

    So perhaps we want kind of more systmatic solution. We already have
    -fvect-cost-model that is kind of vectorizer version of the proposed
    inliner option.
 2) inliner is already quite painful to tune. Especially since 
     one really needs to benchmark packages significantly bigger than
     SPECs which tends to be bit hard to set up and benchmark
     meaningfully. I usually do at least Firefox and clang where the
     first is always quite some work to get working well with latest
     GCC. We SUSE's LNT we also run "C++ behchmarks" which were
     initially collected as kind of inliner tests with higher
     abstraction penalty (tramp3d etc.).

     For many years I benchmarked primarily -O3 and -O3 + profile
     feedbcak on x86-64 only with ocassional look at -O2 and -Os
     behaviour which were generally more stable.
     I also tested other targets (poer and aarch64) but just
     sporadically, which is not good.

     After GCC5 I doubled testing to include both lto/non-lto variant.
     Since GCC10 -O2 started to envolve and needed re-testing too
     (lto/nonlto). One metric I know I ought to tune is -O2 -flto and
     FDO which used to be essentially -O3 before the optimization level
     --params were introduced, but now -O2 + FDO inlining is more
     conservative which hurts, for example, profiledbootstrapped GCC.

     So naturally I am bit worried to introduce even more combinations
     that needs testing and maintenance.  If we add user friendly way to
     tweak this, we also make a promise to keep it sane.