From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 834CC3858C53; Fri, 9 Feb 2024 07:59:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 834CC3858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707465559; bh=Y5QjReKf0hFwKVoeezpSC6+z2jaETzQIoMTnYFuGYBk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ScZbzWEOnyONmt6zaxsOwkVpBQQojauklhetoglHQU2EEmObiwih1VriHM8KPbfSQ ZNzXM0Bh9vkUgGemVOkpag2VWGuUWVzWswpDihDBerf1iglChnyDk/KZrGn6Q2dM0Y 8zTUWyyevUTGq/jAZWrs73715kCWjAw6oTuEdKJY= From: "xry111 at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113838] regression of redundant load operation introduced by -fno-tree-forwprop introduce Date: Fri, 09 Feb 2024 07:59:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: xry111 at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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: cc Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113838 Xi Ruoyao changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- (In reply to absoler from comment #3) > The gimple ir has no problem, but `_13` is replaced with g_26[5][3][0] in > the follow-up process, this shouldn't be expected behavior. >=20 > We question this option because we found in an older version of gcc > (10.2.0), only the O2 option is needed to produce the same bad code, so we > worry about there's a hidden un-fixed problem and it's re-triggered by th= is > option. >=20 > Besides, the bad binary code introduce more load operation than the source > code (without optimization), so we thought it's necessary to check it > regardless of which optimization is disabled. (In reply to absoler from comment #5) > (In reply to Andrew Pinski from comment #2) > > The difference from the gimple level IR: > > ``` > > _14 =3D g_26[5][3][0]; > > _15 =3D (int) _14; > > _16 =3D _13 ^ _15; > > g_51 =3D _16; > > if (_13 !=3D _15) > > ``` > >=20 > > vs: > > ``` > > _14 =3D g_26[5][3][0]; > > _15 =3D (int) _14; > > _16 =3D _13 ^ _15; > > g_51 =3D _16; > > if (_16 !=3D 0) > > goto ; [50.00%] > > else > > goto ; [50.00%] > > ``` > >=20 > >=20 > > This is expected behavior even for the x86_64 target >=20 > The gimple ir has no problem, but `_13` is replaced with g_26[5][3][0] in > the follow-up process, this shouldn't be expected behavior. No. GIMPLE pass knows nothing about register pressure, _13 is only a tempo= rary variable, not necessarily an register. > We question this option because we found in an older version of gcc > (10.2.0), only the O2 option is needed to produce the same bad code, so we > worry about there's a hidden un-fixed problem and it's re-triggered by th= is > option. So are you expecting a bug must be fixed in at least two different passes a= nd any -fno-* option shouldn't regress the code? No this won't happen.=