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 92BA63858D39; Mon, 27 Mar 2023 08:26:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 92BA63858D39
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1679905613;
	bh=zOGX0llHHmOCMfPe2csTMRkZDlXorJ8bmVbOPnBsxBI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fTaeq/EDbrTgilxbpMyYq3BzWlrghd7qriBnL71UV4qDp4GjwnEwgBKPBST/s1F/x
	 WLsILtrbqzzh6gAi1YwM7T06UcSFXWOtU5zqdv4rKgEFkDmWk+6b+VG+N4fCIJFg12
	 gEg0d4ML/QMc3W0qv4D53P7732mtt4gf7WyJ50rA=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109048] [13 regression] redundant mask
 compare generated by vectorizer.
Date: Mon, 27 Mar 2023 08:26:41 +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: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109048-4-ALd6Co0rvo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109048-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109048-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=3D109048

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
The first threadfull pass ends up producing the three-argument PHI:

<bb 7> [local count: 1063004408]:
_7 =3D (long unsigned int) i_14;
_8 =3D _7 * 4;
_9 =3D af_24(D) + _8;
x_25 =3D *_9;
if (x_25 >=3D 0.0)
  goto <bb 9>; [59.00%]
else
  goto <bb 8>; [41.00%]

<bb 8> [local count: 435831803]:

<bb 9> [local count: 1063004408]:
# iftmp.2_17 =3D PHI <iftmp.1_16(7), 1.0e+0(8)>
if (iftmp.0_15 > x_25)
  goto <bb 11>; [50.00%]
else
  goto <bb 10>; [50.00%]

and we thread 9->11 from 8->9 (so when !(x_25 >=3D 0.0)).  Like a related PR
this is a threading that turns a "conditional move" diamond into something =
more
complicated.  We could heuristically decide that we don't want to do this
[early?].  But it might be more honest to more aggressively represent
those as COND_EXPRs then.

So I think we have a duplicate for this.=