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 9C87E3858D28; Mon,  6 Nov 2023 10:06:40 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C87E3858D28
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1699265200;
	bh=oNjmE1MSO6fFqVt4ZhAeIg95/RBDKPNcxjL1IisMd8s=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OqUMetSniSpGySmp6JiN8KYnwpwtlVZVDyuxncqqcsOTfilnXmFh8GqAAZkSVOIx8
	 kJuQSd63yjsAgy3lBzhlC8suhCi4CfvvbvirylKk7dJ0xari8axjoXDSdfKg9Li59d
	 wy1sPoS/0kAJJRsmDf7S8wA5cZoprtgtzz7BOyt4=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/112361] [14 Regression] avx512f-reduce-op-1.c
 miscompiled since r14-5076
Date: Mon, 06 Nov 2023 10:06:38 +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: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-112361-4-UaelY4Eg20@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112361-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112361-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=3D112361

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 6 Nov 2023, rdapp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112361
>=20
> --- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> So "before" we created
>=20
>   vect__3.12_55 =3D MEM <vector(16) float> [(float *)vectp_a.10_53];
>   vect__ifc__43.13_57 =3D VEC_COND_EXPR <mask__24.9_52, vect__3.12_55, { =
0.0,
> 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0=
 }>;
> //  _ifc__43 =3D _24 ? _3 : 0.0;
>   stmp__44.14_58 =3D BIT_FIELD_REF <vect__ifc__43.13_57, 32, 0>;
>   stmp__44.14_59 =3D r3_29 + stmp__44.14_58;
>   ...
>=20
> in vect_expand_fold_left.

Note that this wasn't correct in all cases (wrt signed zeros and
sign-dependent rounding).

> Now, as intended, there is no VEC_COND anymore and we just create the bit=
-field
> reduction over the unmasked vector.

That's invalid for a COND_OP.  We either have to emulate that COND_OP
by materializing a VEC_COND_EXPR as before when that's semantically
valid, or refrain from vectorizing (I don't think we want to emit
N compare & jump to scalarize the mask effect).

> We could refrain from creating the COND_OP in the first place as Jakub
> mentioned (I guess we know already in if-conv that we shouldn't), re-inse=
rt a
> VEC_COND or create a COND_OP chain (instead of an OP chain) in
> vect_expand_fold_left by passing it the mask (and is_cond_op).
> Having several COND_OPs here might make analysis of subsequent passes more
> difficult?

pass in the mask and is_cond_op and create the VEC_COND_EXPR in
vect_expand_fold_left.  But make sure to disallow vectorizing the
invalid cases.=