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 79504384AB58; Wed, 24 Apr 2024 14:16:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79504384AB58
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713968180;
	bh=ANs8qie1CfMHRiV9j6JwL3z5akswP0Q65O3uR6Z7sGk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=nyM1qMmIH4ZXmjmcMqYo8xPJzeKwVUTaaTajSD5Z9yvAYpSZabhUrHx1U+GOXD30T
	 tI1BfWdmKrqyMb9+dSmcVVYvhfCQKg9sP6s/eIz156Iv+ESDSzcwb1jhfMq6YhxSj1
	 0URR7BewdrjbrWLOEdwDrzFhZsW0PEIDUqPJxAN0=
From: "rdapp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with
 -flto -O3 -mrvv-vector-bits=zvl
Date: Wed, 24 Apr 2024 14:16:19 +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: 14.0
X-Bugzilla-Keywords: needs-bisection, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rdapp at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: cc
Message-ID: <bug-114734-4-pBJTz2nPOS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114734-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114734-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=3D114734

Robin Dapp <rdapp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
This one is really a bit tricky.

We have the following situation:

loop:
<bb 3>
# vectp_g.178_1078 =3D PHI <vectp_g.178_1079(3), &gD.2750(2)>=20
_911 =3D &MEM... vectp_g.178_1078
MASK_LEN_LOAD (_911, ...);
vectp_g.178_1079 =3D vectp_g.178_1078 + 16;
goto loop;

<bb 4>:
MASK_LEN_LOAD (_911, ...);

During expand we basically convert back the _911 to vectp_g.178_1078 (rever=
ting
what we did in ivopts before).  Because _911 camouflages vectp_g.178_1078 u=
ntil
expand we evaded the conflict checks of outof-ssa that would catch a simila=
r,
non-camouflaged situation like:

# vectp_g.178_1078 =3D PHI <vectp_g.178_1079(3), &gD.2750(2)>=20
MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...);
vectp_g.178_1079 =3D vectp_g.178_1078 + 16;
goto loop;
MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...);

and would insert a copy of the definition right before the backedge.  The
MASK_LEN_LOAD after the loop would then use that copy.  By using _911 inste=
ad
of the original pointer no conflict is detected and we wrongly use the
incremented pointer.  Without the ivopt change for TARGET_MEM_REF

Unless I'm misunderstanding some basic mechanism it's not going to work like
that (and we could also have this situation on aarch64).  What could help i=
s to
enhance trivially_conflicts_p in outof-ssa to catch such TARGET_MEM_REFs he=
re
and handle them similarly to a normal conflict.  I did that locally and it
helps for this particular case but I'd rather not post it in its current ha=
cky
state even if the riscv testsuite looks ok :)  Even if that were the correct
solution I'd doubt it should land in stage 4.

CC'ing Richard Sandiford as he originally introduced the ivopts and expand
handling.=