From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 49EB83857403; Fri, 28 Oct 2022 10:41:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 49EB83857403
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666953696;
	bh=lfqxXvIZcqPWMpdCuPXke8FJKgQd9oHkO6fx8lMwyvU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fNjuHIO9u/3TYaTWcqgi4I+vUiib1vaUUL3bV9RyK8khd7lFXxR4X9fUGGJ06wKMK
	 Zelet8zbjfT/MxQUTQQSndS9WX19UvIaTIN09Wm0T56gk252/DaDBkfNrr3LbpWnAV
	 /GQxfntI0D6b0/MoUIP4OfmuQJlvgj7PP2znbh3I=
From: "rvmallad at amazon dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC
 cpu2017 benchmark
Date: Fri, 28 Oct 2022 10:41:31 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rvmallad at amazon dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107413-4-1NEHWmMz4I@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107413-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107413-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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 =3D 2 or 3?

Here is SPEC cpu2017 fprate perf data for 1-copy rate run. The runs were ru=
n 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.=