[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #33 from hubicka at kam dot mff.cuni.cz ---
With the inliner tweaks (which I hope to get bit more aggressive this
week) we "solved" the wrf compile time with LTO by simply not building
the gigantic functions.  However we still have significant regressions
without LTO. 

Accroding to
https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch
With spec2006 on kabylake with _O2 we have:
Test Name       gcc-6           gcc-7   gcc-8   gcc-9   gcc-10  gcc-11
gcc-trunk
SPECFP          256.464         3.59%   15.50%  19.29%  29.53%  33.44%  43.50%
SPECint         119.368         3.17%   13.60%  17.23%  14.17%  26.58%  33.58%
and spec2007
SPECFP          638.337         5.39%   21.20%  25.40%  50.18% 45.00%   58.72%
SPECint         217.977         4.03%   11.47%  16.17% 13.29%   22.52%  27.28%

Growing SPECFP -O2 build time by over 10% in one release is quite a lot
though it happened previously with gcc7->gcc8 and gcc9->gcc10 (if I remember
correctly gcc10 was caused by Fortran revisiting libgfortran API and
increasing binaries significantly).

The bigger increase in SPECfp compared to SPECint seems to be attributed
to wrf which regresses 122% compared to gcc6. The build time graph is
here
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=116.548.8&plot.1=161.548.8&plot.2=68.548.8&plot.3=206.548.8&plot.4=373.548.8&plot.5=430.548.8&plot.6=30.548.8&

So I think this is still about the most important compile time issue we
have.  I plan to look at the profile updating issues in threader and
hopefully get bit more faimilar with the code to possibly help here.