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 EFCAE3858C2A; Tue, 14 Nov 2023 12:44:57 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFCAE3858C2A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1699965897;
	bh=QVHW8OouM4CKl+wMCIZ0dciOKofWei5FppJswlzerTU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=RGrUK6hY1Dq7kTr5hLic67LBq6XQFgh1L4FKD7evvrCuQHB0pNTiuKpJ7SnFK5DM2
	 bT1pVMOT5biZPW9v0A0mADs+1RLthS4MWZDb9vuel2Zusqd+FLrSQMeebGD8iz7aRx
	 doj0O4r0dpuP523hZuXphuo+s2f/JXY844pS0g68=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109184] [11/12/13/14 Regression] csmith: 2017
 bug with -floop-interchange
Date: Tue, 14 Nov 2023 12:44:56 +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: 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: <bug-109184-4-E1pfNkRtIS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109184-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109184-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=3D109184

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note even when promoting _2 to an array there wouldn't be any data dependen=
ce
between the actual refs.  There's a dependence between stmts, but that does=
n't
exactly capture the issue either.  Consider

int a[1024], b[1024];

void foo()
{=20=20=20=20
  for (int i =3D 0; i < 32; ++i)
    for (int j =3D 0; j < 32; ++j)
      for (int k =3D 0; k < 32; ++k)
        a[j] =3D b[k];
}=20

where interchange of the two outer loops would be valid since b[k] doesn't
change.  Likewise

  for (int i =3D 0; i < 32; ++i)
    for (int j =3D 0; j < 32; ++j)
      for (int k =3D 0; k < 32; ++k)
        {
          b[k] =3D b[k] + 1;
          a[j] =3D 0;
        }

would be valid to interchange.  For the testcase at hand
tree_loop_interchange::valid_data_dependences only gets the l_1930[] update
as data-dependence that's not statically resolved.

If we'd have that ominous _2[i] and

  _2[i] =3D l_1930[k_26] + -1;
  l_1930[k_26] =3D _2[i];
  g_1731[_6] =3D _2[i];

we'd only have extra zero-distance DDRs here and we ignore those.=