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 75A2F385483D; Thu, 18 May 2023 05:53:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75A2F385483D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684389239;
	bh=fE7tjFdYzYVRiC3bhcQMLcZtUu0dfB0jIMZQ+onQ1Wg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=efvbyfl+w7EMfRWjR80MdELeyLNZMvxhlyLjh/ES97oT3LR3y8FL+JsUPq8cw10Ob
	 9YoOUeEfnoi0VVsK6lbMAvagkNG/3H8jQTC5w9j0ZHFZ1UJvdY/cXImyvhiTEpIsNA
	 xKGy8E7+uuutw+7DhALAoqExfL4im/7/w/lTE1zE=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106902] [11/12/13/14 Regression] Program compiled with
 -O3 -mfma produces different result
Date: Thu, 18 May 2023 05:53:58 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106902-4-kkQ15OXBWx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106902-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106902-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=3D106902

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #23)
> (In reply to Alexander Monakov from comment #22)
> > Created attachment 55105 [details]
> > patch 1/3
> >=20
> > (In reply to Richard Biener from comment #21)
> > >=20
> > > Sounds reasonable.  Though I wouldn't use GENERIC folding but instead
> > > some folding-like code in c-family/ that for example would get invoked
> > > by genericization or via the gimplification hook?  If we'd add GENERIC
> > > folding in fold-const.cc or match.pd the chance is that it will pick =
up
> > > FMAs "late".
> >=20
> > Agreed, thank you. I'm working on it. The attached patch implements thi=
s via
> > c_gimplify_expr and passes bootstrap+regtest under 'configure
> > --with-cpu=3Dznver2' (i.e. with fma available by default).
>=20
> Hmm, seems like this should not be in the C family but the generic part of
> gimplifier. Because IIRC Fortran has similar rules but IIRC fortran
> front-end emits PAREN_EXPR a lot more which improves the situtation there=
 ...

The actual worker can be put into generic code but frontends need to set
the rules here I think as they might differ slightly.

As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BO=
TH
though since at least when no extra negations are required the contraction
should also be a win when optimizing for size?

Also I wondered about the PROP_gimple_any check - do we get into the
gimplification langhook after lowering?  I see we are not resetting the
langhook after lowering (only in free-lang-data, but that only runs with LT=
O).
We probably at least should gate the langhook invocation in the gimplifier
with what you added in the patch or specify whether the gimplifier is
invoked from the middle-end via the gimplifier context.

If we go for c-family only the genericize entry could be another place to
handle this.

Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the
multiplication btw?=