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 B400D3858C5E; Mon, 28 Nov 2022 06:29:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B400D3858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669616988;
	bh=ssc7oPCK+mJTKxBMRaOM+P6QSAOzvRlNkgBYnWHFzUE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Q80QUWMibDNgMzPOKddgqhrxDgtesXXh9kiZw0wrORYzeTIRyB5H8A0Hmr3GZ+Fls
	 W+h7Z4mLsCDgAQ7zfCj9JfjPrS0cTneoqbsGzXm0eGNoNHdKHtiv3/VKyD1xgvP84W
	 0aWtclSVVXLpGL2wiDRpU3ehbwo+sWwWJAwNCqyw=
From: "crazylht at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/97832] AoSoA complex caxpy-like loops:
 AVX2+FMA -Ofast 7 times slower than -O3
Date: Mon, 28 Nov 2022 06:29:47 +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: 10.2.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: crazylht at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-97832-4-dRS4zSu8RS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-97832-4@http.gcc.gnu.org/bugzilla/>
References: <bug-97832-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=3D97832

--- Comment #23 from Hongtao.liu <crazylht at gmail dot com> ---

> the blends do not look like no-ops so I wonder if this is really computing
> the same thing ... (it swaps lane 0 from the two loads from x but not the
> stores)

They're computing the same thing since we also do the same "permutation" for
the invariants: f_re and f_imm, can we eliminate that in the vectorizer?

  _232 =3D {f_im_36, f_im_36, f_im_36, f_im_36};
  _231 =3D {f_im_36, f_re_35, f_re_35, f_re_35}; ------- here
  _216 =3D {f_re_35, f_re_35, f_re_35, f_re_35};
  _215 =3D {f_re_35, f_im_36, f_im_36, f_im_36}; ------ and here.
  ivtmp.36_221 =3D (unsigned long) y_41(D);
  ivtmp.38_61 =3D (unsigned long) x_33(D);

  <bb 4> [local count: 214748368]:
  # ivtmp.32_66 =3D PHI <ivtmp.32_65(4), 0(3)>
  # ivtmp.36_64 =3D PHI <ivtmp.36_63(4), ivtmp.36_221(3)>
  # ivtmp.38_220 =3D PHI <ivtmp.38_60(4), ivtmp.38_61(3)>
  # DEBUG c =3D> NULL
  # DEBUG k =3D> 0
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  # DEBUG D#78 =3D> D#79 * 8
  # DEBUG D#77 =3D> x_33(D) + D#78
  _62 =3D (void *) ivtmp.38_220;
  vect_x_im_61.13_228 =3D MEM <const vector(4) double> [(const double *)_62=
];
  vect_x_im_61.14_226 =3D MEM <const vector(4) double> [(const double *)_62=
 +
32B];
  vect_x_re_55.15_225 =3D VEC_PERM_EXPR <vect_x_im_61.14_226,
vect_x_im_61.13_228, { 0, 5, 6, 7 }>;
  vect_x_re_55.23_209 =3D VEC_PERM_EXPR <vect_x_im_61.13_228,
vect_x_im_61.14_226, { 0, 5, 6, 7 }>;
  # DEBUG D#76 =3D> *D#77
  # DEBUG x_re =3D> D#76
  # DEBUG BEGIN_STMT
  # DEBUG D#74 =3D> (long unsigned int) D#75
  # DEBUG D#73 =3D> D#74 * 8
  # DEBUG D#72 =3D> x_33(D) + D#73
  # DEBUG D#71 =3D> *D#72
  # DEBUG x_im =3D> D#71
  # DEBUG BEGIN_STMT
  # DEBUG D#70 =3D> y_41(D) + D#78
  _59 =3D (void *) ivtmp.36_64;
  vect_y_re_63.9_235 =3D MEM <vector(4) double> [(double *)_59];
  vect_y_re_63.10_233 =3D MEM <vector(4) double> [(double *)_59 + 32B];
  vect__42.18_219 =3D .FMA (vect_x_im_61.13_228, _232, vect_y_re_63.10_233);
  vect_y_re_69.17_222 =3D .FNMA (vect_x_re_55.15_225, _231, vect_y_re_63.9_=
235);
  vect_y_re_69.25_206 =3D .FNMA (vect_x_re_55.23_209, _215, vect_y_re_69.17=
_222);
  vect_y_re_69.25_205 =3D .FNMA (_216, vect_x_im_61.14_226, vect__42.18_219=
);=