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.
