[Bug ipa/94472] 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs

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

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

--- Comment #9 from Jan Hubicka <hubicka at ucw dot cz> ---
> --- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Oh, and bugfixing requires to first understand the bug.  Especially for
> performance related issues understanding what goes wrong is important.
> I see no analysis being performed to date.

The problem here is that -O2 -fprofile-use is now using -O2 inliner
limits while previously it used -O3 inliner limit (because -fprofile-use
enables -finline-functions).

I can see this on SPEC GCC, perl, Firefox, real GCC and clang. We now
have performance diference between -O2+FDO and -O3+FDO.

It is something I kind of missed in my testing, because I was testing
-O2 and -O3 + FDO but not -O2+FDO.  I realize that -O2+FDO is kind of
important because we use it in our bootstrap. So i was collecting data
over weekend for Clang, GCC and Firefox.

It is question how agressive we want to be at -O2+FDO but the
observation is that in all these programs the code size growth for -O3
style limits is quite small (bellow 2%) simply because thraining
coverage is quite small in all those programs (sub 10%) and thus the
code size growth for inlining hot calls is acceptable
and thus I think the current defaults are really suboptimal.

I think there are few ways to proceed
 1) make inline limits with FDO to be -O3 ones
 2) invent yet another set of parameters for FDO
 3) increase importance of known_hot hint that is set of calls that are
 known to be hot (either by inlining or by hot attribute).

1 is easiest but bit non-sytematic. I am not really keen about 2 because
if parameter explosion.
However 3 looks like good alternative so I am running benchmarks with
few settings of it, but they take some time.

Honza