From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id CF2223858D32 for ; Mon, 18 Sep 2023 08:07:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF2223858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-503065c4b25so2226846e87.1 for ; Mon, 18 Sep 2023 01:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695024423; x=1695629223; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KeXUaU6th6Xx4mL1OrG+0auJdduRGT3W/CjUXu8Ejio=; b=k5SRDB25s0jCwRfc2c5EkaapcNoYkoSNiQISCcgej2bmxOm5rsTvtOMeVgD3uaIiUH XnJhhWA0kCvFWWnXKp1fU3z81ijtunLqDRHg2zL4N7kjBYLB514I7a5pWWeOC74oEQqI Jn6m4wzjxKwP2vtCRPdi1T4GoX3xd8pW39NkI5PZzmm1ygfim4Y4KyNz0p/GY+hsPeOl ikSEOHPEVoH94u+jf/xxexFjlvcsiaTpGIqlpVOFQxcIrZYIuim3cLmvweGlc3ovYEAW BJOuT10tuAsI0tgQyO1Bb5cImCNWj6lx9JYKe1Ok/34hjJ5/+bdNjNYuiEL1vwt1oV1D f2UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695024423; x=1695629223; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KeXUaU6th6Xx4mL1OrG+0auJdduRGT3W/CjUXu8Ejio=; b=uhRGS7/uOx+NIbASj3qBFaMfLZGajOZJI97RldWOnIZumRj+MyWaWCHisGNskmgZRz yXt56KQQ6UpNNuDRvW+7w83i2X1cag0YJ2t7Ym2cAJN9uCYRk8putzYbPvL7FNOYxsZM DoyVijMMnG9oksWxaTS2CjXjvWYpm3iysDLvkYmR1WhybMrWuWxMMgAaThm3gMi7nlzW +hb73L94iwCNFoMx9WcDLh6/vwBMoFyV5JyWTZcoF3nbQ/McDQFQ5ZikDK1GHMWe0v5W e1APAd61C+kGigh0R/FzcCDmC29lZa4Tze9aTRRHC1dmjBj5+Q5msQYRp30qYuUaaQmt 6YYA== X-Gm-Message-State: AOJu0YzOmONQ2Q86SxdelEIUYDyNHFnGSwFnNELGDHGuzi6+CRFEEanW +42vt3ZsRkMx0gbu6RhJaxX20hYnPtDQ+0mBTKL0agXo X-Google-Smtp-Source: AGHT+IFx8wgAMxmVLj0Bzq0WMtdy0AUC1yVDq8xnFZwRsuAiFT2k9q9jKBizx4YAWZYQlY11s2weGLb1kCmx5GIwlcY= X-Received: by 2002:a05:6512:1597:b0:4fd:fd97:a77b with SMTP id bp23-20020a056512159700b004fdfd97a77bmr8975257lfb.50.1695024423023; Mon, 18 Sep 2023 01:07:03 -0700 (PDT) MIME-Version: 1.0 References: <87r0n01z18.fsf@oldenburg3.str.redhat.com> <21e46cef-1fbf-df87-608d-52b7f894dea7@ispras.ru> In-Reply-To: From: Richard Biener Date: Mon, 18 Sep 2023 10:06:51 +0200 Message-ID: Subject: Re: Concerns regarding the -ffp-contract=fast default To: Alexander Monakov Cc: Florian Weimer , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,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: On Mon, Sep 18, 2023 at 9:51=E2=80=AFAM Alexander Monakov wrote: > > Hi Florian, > > On Thu, 14 Sep 2023, Alexander Monakov wrote: > > > > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote: > > > > > While rebuilding CentOS Stream with -march=3Dx86-64-v3, I rediscovere= d > > > several packages had test suite failures because x86-64 suddenly gain= ed > > > FMA support. I say =E2=80=9Crediscovered=E2=80=9D because these issu= es were already > > > visible on other architectures with FMA. > > > > > > 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 ri= ght > > > course of action. > > > > > > GCC contraction behavior is rather inconsistent. It does not contrac= t x > > > + x - x without -ffast-math, for example, although I believe it would= be > > > permissible under the rules that enable FMA contraction. This whole Is that really just x + x - x? We currently gate simplifying x - x to zero on no-signed-zeros and round-to-nearest and have no special handling for x + x - x. > > > thing looks suspiciously like a quick hack to get a performance > > > improvement from FMA instructions (sorry). > > > > > > 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-/ > > > > 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 speak = of > > to remain with =3Dstandard as opposed to =3Doff. > > > > 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. > > > > (personally I'd be on board with switching to =3Doff even) > > > > See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contra= ct=3Dfast > > caused a correctness issue in a widely used FOSS image processing appli= cation > > that was quite hard to debug. > > > > Obviously -Ofast and -ffast-math will still imply -ffp-contract=3Dfast = if we > > make the change, so SPEC scores won't be affected. > > Is this the sort of information you were looking for? > > If you're joining the Cauldron and could poll people about changing the d= efault, > I feel that could be helpful. > > One of the tricky aspects is what to do under -std=3DcNN, which implies > -ffp-contract=3Doff; "upgrading" it to =3Dstandard would introduce FMAs. > > Also, I'm a bit unsure what you were implying here: > > > 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, it > > probably has an observable performance impact. 8-/ > > 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. 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 requ= ire =3Doff anywhere. Richard. > > Thanks. > Alexander