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 F1D1E3858017; Wed, 27 Sep 2023 02:45:12 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1D1E3858017
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1695782712;
	bh=c8AIpvAKedJNNTf0x/xHE88QylH1JUtzWZf+dtAw3kQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vIQwqL7WFjxU2Id+zgVWSiFMiE1Iqp4NHlxIvxMjARTFUkq2Keun1DbCJArAc8cNJ
	 rqDl46CogkRvlBkw3FFsSiKXIisBsGRjb+DKXpFQFJ3HqXd7uBjVYynTCBTMFEUVor
	 9vyQMlVb34DplAnySMggF2wObOLcsMc/cwjhltcE=
From: "juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109088] GCC does not always vectorize
 conditional reduction
Date: Wed, 27 Sep 2023 02:45:12 +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: enhancement
X-Bugzilla-Who: juzhe.zhong at rivai dot ai
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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-109088-4-E0Du4VcWpT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109088-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109088-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=3D109088

--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
Update the analysis:

We failed to recognize it as reduction because, the PHI result has 2 uses:

# result_20 =3D PHI <result_9(8), 0(18)>
...
_11 =3D result_20 + 10;   --------> first use
result_17 =3D _4 + _11;
_23 =3D _4 > _7;
result_9 =3D _23 ? result_17 : result_20;  -----> second use

It seems that it is the if-conversion issue which makes loop vectorizer fai=
led
to vectorize it.

I have checked LLVM implementation, their "result" ssa always has single us=
e no
matter how I modify the codes (for example, result +=3D a[i] + b[i] + c[i])=
.=