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 AF9983858D38; Fri, 22 Mar 2024 07:38:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF9983858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1711093122;
	bh=V3uA3x5P8sHSxMvov9+IWMVewa5OL3GyitMmbpMsN70=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=iJ4gye7q/EyLqVhCIT0fprUqZiDTAg1YiALHGME9+M5eWA8QeeOndIv2pGiz6RNXd
	 rZZEFSbQrmCIs0k1mkFvOYJZOSf4oqaM2VJ1Cg5AywmAu6tvivxN6NqNKcCzj/fgp5
	 0ADonzNrS4x3EEi0Y7t6VO+p8g+6Nz0cTBMoA1g0=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer
 when using SSE2 intrinsics with -O3 since
 r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
Date: Fri, 22 Mar 2024 07:38:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 10.2.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-111683-4-wRhfO0JVyD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111683-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111683-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=3D111683

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 57766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D57766&action=3Dedit
patch

Oddly enough the following patch doesn't fix it but it correctly prevents us
from recording the access functions and data dependence analysis now says

(Data Dep:
#(Data Ref:
#  bb: 3
#  stmt: _2 =3D MEM[(U * {ref-all})_1];
#  ref: MEM[(U * {ref-all})_1];
#  base_object: MEM[(U * {ref-all})_1];
#)
#(Data Ref:
#  bb: 3
#  stmt: _7 =3D MEM[(U * {ref-all})_6];
#  ref: MEM[(U * {ref-all})_6];
#  base_object: MEM[(U * {ref-all})_6];
#)
    (don't know)

but predictive commoning still does

Store-loads chain 0x48229b0
  max distance 2, may reuse first
  inits MEM[(U * {ref-all})&c] MEM[(U * {ref-all})&c + 8B]
  references:
    MEM[(U * {ref-all})_6] (id 3, write)
      offset -2
      distance 0
    MEM[(U * {ref-all})_1] (id 0)
      offset 0
      distance 2

Executing predictive commoning without unrolling.

predcom has its own analysis it seems and it makes a similar mistake.=