[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark

[rvmallad at amazon dot com]

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

--- Comment #5 from Rama Malladi <rvmallad at amazon dot com> ---
(In reply to Wilco from comment #2)
> That's interesting - if the reassociation pass has become a bit smarter in
> the last 5 years, we might no longer need this workaround. What is the
> effect on the overall SPECFP score? Did you try other values like
> fp_reassoc_width = 2 or 3?

Here is SPEC cpu2017 fprate perf data for 1-copy rate run. The runs were run on
a c7g.16xlarge AWS cloud instance.

Benchmark       w fix
----------------------
503.bwaves_r    0.98
507.cactuBSSN_r NA
508.namd_r      0.97
510.parest_r    NA
511.povray_r    1.01
519.lbm_r       1.16
521.wrf_r       1.00
526.blender_r   NA
527.cam4_r      1.00
538.imagick_r   0.99
544.nab_r       1.00
549.fotonik3d_r NA
554.roms_r      1.00
geomean         1.01

The baseline was gcc version 12.2.0 (GCC) compiler. Fix was revert of code
change in commit: b5b33e113434be909e8a6d7b93824196fb6925c0.

So, looks like we aren't impacted much with this commit revert.

I haven't yet tried fp_reassoc_width. Will try shortly.