From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AC09638582A5; Thu, 1 Feb 2024 12:53:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC09638582A5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1706791992; bh=mUi9bOuKgrOkvN/US/npZIYIHW6dYg0SFPNfUENV7rs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=G9/074PkFjIYBruZLHs7918+E9bN/SEtq2EVqs22H2wnWygGrN6n8t2BCPcW4l/1/ TyQfjqSHCcSb0BiefQFHWzeTSMVvy8RxC6F/ed6Diymqq7MZb0RwOPvJThS6HpSW+i /XTR1wKOqbNCRVnaz31zLBIvHv9PG7WldGZetn20= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/113255] [11/12/13 Regression] wrong code with -O2 -mtune=k8 Date: Thu, 01 Feb 2024 12:53:10 +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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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=3D113255 --- Comment #15 from Richard Biener --- The issue is also that via CSELIB we go from the good (minus:DI (reg/f:DI 119) (reg:DI 115)) to (minus:DI (value:DI 11:11 @0x41fca00/0x41ec410) (value:DI 10:15448 @0x41fc9e8/0x41ec3e0)) and later when DSE does cselib_expand_value_rtx on the value it produces (minus:DI (reg/f:DI 119) (minus:DI (reg/f:DI 120) (reg/f:DI 114))) which simplify_rtx then turns into (minus:DI (plus:DI (reg/f:DI 114) (reg/f:DI 119)) (reg/f:DI 120)) note how that associates things in a way that confuses us later. In partic= ular the loc for (value:DI 10:15448) (aka the inner minus) isn't REG_POINTER (after you fix i386 RTL expansion) but after the re-assloc there's only the wrong REG_POINTER immediately visible. DSE gets this all back-and-forth into/out-of CSELIB, it feels a bit of a me= ss. It obviously relies on the expansion to discover base values. First the x86 backend should avoid having a REG_POINTER as the pointer difference: diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc index 0d817fc3f3b..26c48e8b0c8 100644 --- a/gcc/config/i386/i386-expand.cc +++ b/gcc/config/i386/i386-expand.cc @@ -8090,7 +8090,7 @@ expand_set_or_cpymem_prologue_epilogue_by_misaligned_moves (rtx destmem, rtx src /* See how many bytes we skipped. */ saveddest =3D expand_simple_binop (GET_MODE (*destptr), MINUS, saved= dest, *destptr, - saveddest, 1, OPTAB_DIRECT); + NULL_RTX, 1, OPTAB_DIRECT); /* Adjust srcptr and count. */ if (!issetmem) *srcptr =3D expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr, We can avoid the issue by avoiding re-association of pointer MINUS: diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index ee75079917f..0108d0aa3bd 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -3195,11 +3195,15 @@ simplify_context::simplify_binary_operation_1 (rtx_= code code, canonicalize (minus A (plus B C)) to (minus (minus A B) C). Don't use the associative law for floating point. The inaccuracy makes it nonassociative, - and subtle programs can break if operations are associated. */ + and subtle programs can break if operations are associated. + Don't use the associative law when subtracting a MINUS from + a REG_POINTER as that can trick find_base_term into discovering + the wrong base. */ if (INTEGRAL_MODE_P (mode) && (plus_minus_operand_p (op0) - || plus_minus_operand_p (op1)) + || ((!REG_P (op0) || !REG_POINTER (op0)) + && plus_minus_operand_p (op1))) && (tem =3D simplify_plus_minus (code, mode, op0, op1)) !=3D 0) return tem; or we can avoid it with a more dangerous (IMHO) "fix" like the following which while it looks good on the front, isn't reliable and might instead trick find_base_term to deflect to another invalid base. diff --git a/gcc/alias.cc b/gcc/alias.cc index 3672bf277b9..f589a1fa47a 100644 --- a/gcc/alias.cc +++ b/gcc/alias.cc @@ -2094,7 +2101,14 @@ find_base_term (rtx x, vec