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 E8C91385DDE7; Tue, 11 Jun 2024 09:07:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8C91385DDE7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1718096859;
	bh=g18NN1DkQeRybb04J2TAv/rmQ+aO1t4BcYXl6+onY4A=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=emW456dMmYzWuT9ogFtoNOWx6qBXbFaTjX83nLlSM1eSyfDcHx8JcH35/zx3Ka4CL
	 Fx/9GXZQmoAodXOeUflnlA57Is6hcYHoTROcrbASYP6iTroKX4nZ9S+iL1CRI1kzXq
	 WI4W0ZulehV4j7ub1mWIrcI9rAds5vdhjC/mPjVs=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/115427] fallback for interclass mathfn bifs
 like isinf, isfinite, isnormal
Date: Tue, 11 Jun 2024 09:07:39 +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: 15.0
X-Bugzilla-Keywords: internal-improvement
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-115427-4-mrivFBTwpq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-115427-4@http.gcc.gnu.org/bugzilla/>
References: <bug-115427-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=3D115427

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 11 Jun 2024, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115427
>=20
> --- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #2)
> > The canonical way would be to handle these in the ISEL pass and remove
> > the (fallback) expansion.  But then we can see whether the expander FAI=
Ls
> > (ideally expanders would never be allowed to FAIL, and for FAILing expa=
nders
> > we'd have a way to query the target like we have the vec_perm_const hoo=
k).
> >=20
> > But I'll note that currently the expanders may FAIL but then we expand =
to
> > a call rather than the inline-expansion (and for example AVR relies on =
this
> > now to avoid early folding of isnan).
> >=20
> > So - for the cases of isfininte and friends without a fallback call I
> > would suggest to expand from ISEL to see if it FAILs and throw away
> > the result (similar as how IVOPTs probes things).  Or make those _not_
> > allowed to FAIL?  Why would they fail to expand anyway?
>=20
> Thanks for the suggestion! IIUC considering the AVR example we still want
> *isinf* to fall back with the library call (so not falling back with
> inline-expansion way then).  Currently at least for rs6000 port there is =
no
> case that we want to make it FAIL, but not sure some other targets will h=
ave
> such need in future.  From the review comment[1], we don't note it's not
> allowed to FAIL so we probably need to ensure there is some handling for =
FAIL
> in case some future FAIL cause some unexpected failure. Do you prefer not
> allowing it to FAIL? then re-open this and go with ISEL if some port want=
s it
> to FAIL?

I think it would be cleaner to not allow it FAIL since there's no library
fallback.  FAILing patterns are a hassle when it comes to GIMPLE
optimizations.

As said, there should be a good reason why patterns FAIL - what's
the idea behind this feature anyway?=