From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 1ED3E385783F for ; Thu, 16 Mar 2023 16:31:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1ED3E385783F 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-pf1-x42a.google.com with SMTP id b20so1487332pfo.6 for ; Thu, 16 Mar 2023 09:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678984307; 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=O28tLwsnSLa8AoZv4BZc864Uyo2WjBmFu1kAGMOIqBc=; b=kTHSB6CVjxhDxj8e2R1nHLrZQMagYuQescN6974Y3J0gmZ9CZcEgGoY9RvufhCK5BT KyZkq0ABPNfvuiBAfIrPFNiKgTREobLoEOJu2Tf6jb1pbkoO55u/w3XJ4vW3zj+Hxcep NuwT2K7YFeO2Bua2JPSq+QAjyV0uaQ4XC3h23gbREScsT/NerFOSg0kL2Qnfkx6s7Z/9 3/s099JjJ+EbpcGocM7pr3v99hEqrA/tNIt2AifFNqgNGn3ajFcgNIt7Dn7leNS0sBRJ hEnvo67U5/+WoIBVT9i0ZnZucAKo2PFIEGs2xA+gjNS3aQ5/fO70t3cjpx4XQAjpzxaX gxrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678984307; 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=O28tLwsnSLa8AoZv4BZc864Uyo2WjBmFu1kAGMOIqBc=; b=KEborefYIJxOB+d6JmyBZ4tQa2WEUuwh6iz9SWy618t0fEgZ+irjA0QNZh/83pHMaz /uLDERQT7A6YDv4VEXHqAsWaRaupdd+nvSRpfoq9vwwMCzgvdKW0VLTyFe8SdlzE8WPt bG1NPavzPEnysxU5dzxfKCx141fC8Ma1hfhCErKuveqA4PPSVWCvWuFU73ODbFLPPRQ/ MArfg4IPLLsoj2YBiH9cZCl9P8lJF4JV7iFinvd8mgJWJhLDGArV5rGUWl1tEEmSj9uI KK6WwYn3m+kEgrbbBlDX7QDhcsJj//cHUqOokcRt0qZILfKLwDX4BBVX+0Ze3ORxbyLJ 0IMA== X-Gm-Message-State: AO0yUKU60Rr7rK0TZa5WG/l6XRsODwJR0R14dHenW6k81FkaC3uX7mGI SL7EcyMOgofU2I9z7IRyj9tAj4BPIgLTvw9Af78= X-Google-Smtp-Source: AK7set/1XFU+VVHseYnkWunFMaqOqoHG/sourtAq9bZjtYj0P9v1uXPEXIT0o3rEQdSdy79Ci8yyKL3hJzTBW98m75Y= X-Received: by 2002:a05:6a00:1a8e:b0:61c:67d2:a332 with SMTP id e14-20020a056a001a8e00b0061c67d2a332mr14951pfv.3.1678984306856; Thu, 16 Mar 2023 09:31:46 -0700 (PDT) MIME-Version: 1.0 References: <6659A77B-DA2F-40A6-BDBD-E8B29B9E901D@oracle.com> In-Reply-To: <6659A77B-DA2F-40A6-BDBD-E8B29B9E901D@oracle.com> From: Andrew Pinski Date: Thu, 16 Mar 2023 09:31:34 -0700 Message-ID: Subject: Re: Should -ffp-contract=off the default on GCC? To: Qing Zhao Cc: "richard.earnshaw@arm.com" , gcc Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Mar 16, 2023 at 9:25=E2=80=AFAM Qing Zhao via Gcc-patches wrote: > > Hi, > > Recently, we discovered some floating point precision diffs when using GC= C8 to build our > application on arm64: After some investigation, it turns out that this is= due to the > -ffp-contract=3Dfast option that is on by default. Therefore, we have to = explicitly add > -ffp-contract=3Doff and do a full-rebuild. > > GCC by default turns -ffp-contract=3Dfast on. > https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/Optimize-Options.html#Optimi= ze-Options > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#Optim= ize-Options > > " > -ffp-contract=3Dstyle > -ffp-contract=3Doff disables floating-point expression contraction. -ffp-= contract=3Dfast enables > floating-point expression contraction such as forming of fused multiply-a= dd operations if > the target has native support for them. -ffp-contract=3Don enables floati= ng-point expression > contraction if allowed by the language standard. This is currently not im= plemented and > treated equal to -ffp-contract=3Doff. > > The default is -ffp-contract=3Dfast. > " > > This can be shown by a small example for arm64 with gcc8.5 in https://god= bolt.org/z/MxYfnG8TE. > Only when adding -std=3Dc89 explicitly, this transformaton is off. > > another exmaple also shows that Clang and MSVC only allow this transforma= tion when speifiying > ffast-math and fp:fast: https://godbolt.org/z/o54bYfPbP > > When searching online, we found that there were similar discussions recen= tly on the exact same issue: > https://github.com/dotnet/runtime/issues/64604 > https://github.com/dotnet/runtime/issues/64591 > > a summary of these discussions is: > > 1. "fmadd" is a fused operation and will return a different result for ma= ny inputs; > 2. therefore, -ffp-contract=3Dfast is not a safe optimization to be on by= default; > 3. Clang and MSVC only allow this when specifying ffast-math and fp:fast = since this is not an > IEEE754 compliant optimization; > 4. The reasons why GCC turns on this option by default are: > A. GNU C language spec allows such transformation. > B. this did not expose real problem for most X86/X64 apps previously si= nce FMA instructions > didn't exist until 2013 when the FMA3 instruction set was added, and= also these instructions > were not always available.. > 5. Arm64 has fused multiply-add instructions as "baseline" and are always= available. therefore > -ffp-contract=3Dfast exposed more serious problems on Arm64 platforms. This summary ignores x87 and even ignores PowerPC in GCC having FMA even before clang/LLVM was around. > > our major question: > > Should GCC turn off -ffp-contract=3Dfast by default since it's not IEEE75= 4 compliant and more > modern processors have the FMA instructions available by default? NO. We have this debate every few years and such. Thanks, Andrew Pinski > > Thanks. > > Qing