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 C9FFE3858D33; Mon, 26 Jun 2023 09:41:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C9FFE3858D33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1687772512;
	bh=E9JFtqeT4eW0QpMZsxJZMA/0QaVMVJFU7cm1aR9kSXM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=F0cXtmqZBABBo5y+Q6hKM1kDeRSusVJtgk+PnsULsZzXz8MQjaJYvQfOsHD0MkZpO
	 l0RAAeFa4qYQqVfJlrC+RRytNBWGvy0grC3eTn7W7+bENUExR0JI6z425YFDIiSAFL
	 YPSnQMDefLLZ30BMMZqGmdkLUvXnJCUXQUSHh2To=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110381] [11/12/13/14 Regression] double
 counting for sum of structs of floating point types
Date: Mon, 26 Jun 2023 09:41:51 +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: 12.1.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: P3
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-110381-4-YaDgERva7N@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110381-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110381-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=3D110381

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so we transform the in-order FOLD_LEFT_REDUCTION as

  # sum_22 =3D PHI <sum_15(5), 0.0(2)>
  # vectp_foos.7_25 =3D PHI <vectp_foos.7_23(5), foos_12(D)(2)>
...
  vect_foo_c_8.9_21 =3D MEM <vector(2) double> [(double *)vectp_foos.7_25];
  vectp_foos.7_20 =3D vectp_foos.7_25 + 16;
  vect_foo_c_8.10_7 =3D MEM <vector(2) double> [(double *)vectp_foos.7_20];
  vectp_foos.7_6 =3D vectp_foos.7_25 + 32;
  vect_foo_c_8.11_5 =3D MEM <vector(2) double> [(double *)vectp_foos.7_6];
  stmp_sum_13.12_4 =3D BIT_FIELD_REF <vect_foo_c_8.9_21, 64, 0>;
  stmp_sum_13.12_31 =3D sum_22 + stmp_sum_13.12_4;
  stmp_sum_13.12_32 =3D BIT_FIELD_REF <vect_foo_c_8.9_21, 64, 64>;
  stmp_sum_13.12_33 =3D stmp_sum_13.12_31 + stmp_sum_13.12_32;
  stmp_sum_13.12_34 =3D BIT_FIELD_REF <vect_foo_c_8.10_7, 64, 0>;
  stmp_sum_13.12_35 =3D stmp_sum_13.12_33 + stmp_sum_13.12_34;
  stmp_sum_13.12_36 =3D BIT_FIELD_REF <vect_foo_c_8.10_7, 64, 64>;
  stmp_sum_13.12_37 =3D stmp_sum_13.12_35 + stmp_sum_13.12_36;
  stmp_sum_13.12_38 =3D BIT_FIELD_REF <vect_foo_c_8.11_5, 64, 0>;
  stmp_sum_13.12_39 =3D stmp_sum_13.12_37 + stmp_sum_13.12_38;
  stmp_sum_13.12_40 =3D BIT_FIELD_REF <vect_foo_c_8.11_5, 64, 64>;
  foo$a_11 =3D _3->a;
  foo$b_9 =3D _3->b;
  foo$c_8 =3D _3->c;
  sum_13 =3D stmp_sum_13.12_39 + stmp_sum_13.12_40;
  sum_14 =3D foo$b_9 + sum_13;
  sum_15 =3D foo$a_11 + sum_14;

where you can see the final step updates one but not the last scalar stmt
in the SLP reduction group.  That causes us to keep the scalar reads live
and apply some elements multiple times.=