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 224E23858C5F; Tue, 21 Mar 2023 15:36:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 224E23858C5F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679412991;
	bh=twMf5R5SHnrujYb66iIB2Msojli0Mw6s3vBX3kiGadU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=G05sJUhWlRXL48DLQFuFwe9+8nM7iCA8VozxDzRjNyn26rjCrpk/KG3CgX2WrOV8H
	 7nM8wetzJRckjnJFzrnRiqzWGyKo7FXtP0lJLCYsIxhO1hKYWMUFFTcmDZtv4t4olW
	 cSqbSkqxMrdCd5ylfqA7nK3jRPDUuf7Oec/g39Oc=
From: "avieira at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109230] [13 Regression] Maybe wrong code for
 opus package on aarch64 since r13-4122-g1bc7efa948f751
Date: Tue, 21 Mar 2023 15:36:30 +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: avieira at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109230-4-tHik6vjA2B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109230-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109230-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=3D109230

--- Comment #6 from avieira at gcc dot gnu.org ---
Thanks!

My initial investigation has lead me to think the change is being caused at
vrp2, which is the only time the pattern gets triggered with -O2, the tree
before the pass (at the place where the transformation happens):

  vect__83.466_787 =3D VEC_PERM_EXPR <vect__83.456_796, vect__83.456_796, {=
 1, 1
}>;
  vect__87.467_786 =3D vect__81.462_791 * vect__83.466_787;
  vect__91.469_784 =3D vect__84.458_794 - vect__87.467_786;
  vect__88.468_785 =3D vect__84.458_794 + vect__87.467_786;
  _783 =3D VEC_PERM_EXPR <vect__88.468_785, vect__91.469_784, { 0, 3 }>;
 ...
  vect__96.470_782 =3D vect__95.450_800 - _783;

after the pass:
  vect__83.466_787 =3D VEC_PERM_EXPR <vect__83.456_796, vect__83.456_796, {=
 1, 1
}>;
  vect__87.467_786 =3D vect__83.466_787 * vect__81.462_791;
  vect__91.469_784 =3D vect__84.458_794 - vect__87.467_786;
  vect__88.468_785 =3D vect__87.467_786 + vect__84.458_794;
  _756 =3D VIEW_CONVERT_EXPR<double>(vect__87.467_786);
  _755 =3D -_756;
  _739 =3D VIEW_CONVERT_EXPR<vector(2) float>(_755);
  _783 =3D _739 + vect__84.458_794;
...
  vect__96.470_782 =3D vect__95.450_800 - _783;

So before we had:
_783 =3D the first element of vect_88 and the second element of vect__91
these are respectively
vect__88 =3D vect__84 + vect__87
vect__91 =3D vect__84 - vect__87
so _783 =3D {vect__84[0] + vect__87[0], vect__84[1] - vect__87[1]}

after the pass
_783 =3D _739 + vect__84
This is where I don't know if I'm reading the optimization correctly, but it
says all 'even' lanes are negated, does that mean we end up with:
_739 =3D { -vect__87[0] , vect__87[1]}
if so then that's why we have a wrong result as you want to negate lane 1 n=
ot
0.  Otherwise if lane 1 is the one that gets negated then it should be OK as
you'd get:
so _783 =3D { vect__87[0] + vect__84[0], -vect__87[1] + vect__84[1] }
Now obviously that's assuming -a + b =3D=3D b - a (not sure if that's true =
with
floating point errors etc)=