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 943673861897; Wed, 27 Sep 2023 09:27:21 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 943673861897
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1695806841;
	bh=tkDvd7yYcv17n4wMLr2L3WFUX1X9oMf7O1A1ZujoWR8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=u1eiGzdxzt63nVjv4SX6NoKRuSyu8xBsTHSXDOlWm72xzYphNM/NQt4FfubNxKXbD
	 uDsxyY3vTbmCKJXawtR7BKb1YcbawpYq2CzpCxm4Slj370SL1s21cfkqyfcgz6BXDk
	 i2F7nUX7LAN1BzFMHcpmfrwdh/+pF8rwk5QjPgRk=
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 09:27:20 +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-Pa5DommENh@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 #12 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Richard Biener from comment #11)
> I don't think strip_nop_cond_scalar_reduction is the place to adjust here,
> maybe it's the caller.  I don't have time to dig into the specific issue
> right now but if we require scalar code adjustments then we need to perfo=
rm
> those in if-conversion.
>=20
> But to me it looks like allowing
>=20
> > > STMT 1. tmp =3D a[i] + x;
> > > STMT 2. tmp2 =3D tmp + result_ssa_1;
> > > STMT 3. result_ssa_2 =3D mask ? tmp2 : result_ssa_1;
>=20
> in vect_is_simple_reduction might also be a reasonable approach.  The
> use in the COND_EXPR isn't really a use - it's a conditional update.

Thanks Richi.

Enhancing vect_is_simple_reduction in loop vectorizer is also a good approa=
ch.
But I think it's better to recognize the scalar condition reduction
(if-conversion) as early as possible. Obviously, current if-conversion fail=
ed
to
recognize it as a feasible conditional reduction.

I think enhancing vect_is_simple_reduction is the approach that it's unlike=
ly
we
can simplify the scalar code in if-converison to fit current loop vectorize=
r.

I believe we will eventually have to enhance both if-converison and loop
vectorizer in the future. And I prefer improving the if-conversion and work=
ing
on it. Will keep you posted.

Thanks a lot!=