From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xmailer.gwdg.de (xmailer.gwdg.de [134.76.10.29]) by sourceware.org (Postfix) with ESMTPS id BE8823858C66 for ; Mon, 18 Sep 2023 11:26:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BE8823858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de Received: from excmbx-02.um.gwdg.de ([134.76.9.217] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1qiCP2-0009Jw-4Q; Mon, 18 Sep 2023 13:26:56 +0200 Received: from EXCMBX-29.um.gwdg.de (134.76.9.204) by EXCMBX-02.um.gwdg.de (134.76.9.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.32; Mon, 18 Sep 2023 13:26:55 +0200 Received: from tug-swl-a110.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.32; Mon, 18 Sep 2023 13:26:55 +0200 Message-ID: Subject: Re: Concerns regarding the -ffp-contract=fast default From: Martin Uecker To: Richard Biener , Alexander Monakov CC: Florian Weimer , Date: Mon, 18 Sep 2023 13:26:54 +0200 In-Reply-To: References: <87r0n01z18.fsf@oldenburg3.str.redhat.com> <21e46cef-1fbf-df87-608d-52b7f894dea7@ispras.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-03.um.gwdg.de (134.76.9.218) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPAM_BODY,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc: > On Mon, Sep 18, 2023 at 9:51=E2=80=AFAM Alexander Monakov wrote: > >=20 > > Hi Florian, > >=20 > > On Thu, 14 Sep 2023, Alexander Monakov wrote: > >=20 > > >=20 > > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > >=20 > > > > While rebuilding CentOS Stream with -march=3Dx86-64-v3, I rediscove= red > > > > several packages had test suite failures because x86-64 suddenly ga= ined > > > > FMA support. I say =E2=80=9Crediscovered=E2=80=9D because these is= sues were already > > > > visible on other architectures with FMA. > > > >=20 > > > > So far, our package/architecture maintainers had just disabled test > > > > suites or had built the package with -fp-contract=3Doff because the > > > > failures did not reproduce on x86-64. I'm not sure if this is the = right > > > > course of action. > > > >=20 > > > > GCC contraction behavior is rather inconsistent. It does not contr= act x > > > > + x - x without -ffast-math, for example, although I believe it wou= ld be > > > > permissible under the rules that enable FMA contraction. This whol= e >=20 > Is that really just x + x - x? We currently gate simplifying x - x to ze= ro > on no-signed-zeros and round-to-nearest and have no special > handling for x + x - x. >=20 > > > > thing looks suspiciously like a quick hack to get a performance > > > > improvement from FMA instructions (sorry). > > > >=20 > > > > I know that GCC 14 has -fp-contract=3Dstandard. Would it make sens= e to > > > > switch the default to that? If it fixes those package test suites,= it > > > > probably has an observable performance impact. 8-/ > > >=20 > > > Note that with =3Dstandard FMA contraction is still allowed within an > > > expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'= . > > > The difference between =3Dfast and =3Dstandard is contraction across > > > statement boundaries. So I'd expect some test suite failures you spea= k of > > > to remain with =3Dstandard as opposed to =3Doff. > > >=20 > > > I think it's better to switch both C and C++ defaults to =3Dstandard, > > > matching Clang, but it needs a bit of leg work to avoid regressing > > > our own testsuite for targets that have FMA in the base ISA. > > >=20 > > > (personally I'd be on board with switching to =3Doff even) > > >=20 > > > See https://gcc.gnu.org/PR106902 for a worked example where -ffp-cont= ract=3Dfast > > > caused a correctness issue in a widely used FOSS image processing app= lication > > > that was quite hard to debug. > > >=20 > > > Obviously -Ofast and -ffast-math will still imply -ffp-contract=3Dfas= t if we > > > make the change, so SPEC scores won't be affected. > >=20 > > Is this the sort of information you were looking for? > >=20 > > If you're joining the Cauldron and could poll people about changing the= default, > > I feel that could be helpful. > >=20 > > One of the tricky aspects is what to do under -std=3DcNN, which implies > > -ffp-contract=3Doff; "upgrading" it to =3Dstandard would introduce FMAs= . > >=20 > > Also, I'm a bit unsure what you were implying here: > >=20 > > > I know that GCC 14 has -fp-contract=3Dstandard. Would it make sense = to > > > switch the default to that? If it fixes those package test suites, i= t > > > probably has an observable performance impact. 8-/ > >=20 > > The "correctness trumps performance" principle still applies, and > > -ffp-contract=3Dfast (the current default outside of -std=3DcNN) is > > known to cause correctness issues and violates the C language standard. > > And -ffast[-and-loose]-math for is not going away. >=20 > I think that changing the default to =3Dstandard without -ffast-math is > reasonable. > IIRC the standard allows such default if it's indicated, so it doesn't re= quire > =3Doff anywhere. The C standard requires a pragma to turn control it on and off,=C2=A0 which GCC does not support. The default is then implementation defined. Martin