From: Florian Weimer <fweimer@redhat.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Alexander Monakov <amonakov@ispras.ru>, gcc@gcc.gnu.org
Subject: Re: Concerns regarding the -ffp-contract=fast default
Date: Mon, 18 Sep 2023 12:10:38 +0200 [thread overview]
Message-ID: <877condc69.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAFiYyc0c9LoKkdbkDfccrdv7LP89dxCvAp3J15L9X-SqVkEgAw@mail.gmail.com> (Richard Biener's message of "Mon, 18 Sep 2023 10:06:51 +0200")
* Richard Biener:
>> > > GCC contraction behavior is rather inconsistent. It does not contract 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.
It's just an example I made up, and checked that GCC wouldn't optimize
it by default (without -ffast-math et al.). I believe the rule that GCC
invokes to introduce FMA under -ffp-contract=standard (and
-ffp-contract=fast) would apply to these contractions as well.
Or put differently, -ffp-contract= seems to be exclusively about FMA,
while the option name and description is more generic.
x - x is different because replacing it with 0 doesn't seem to be a
valid contraction because it's incorrect for NaNs. x + x - x seems to
be different in this regard, but in our implementation, there might be a
quirk about sNaNs and qNaNs.
>> The "correctness trumps performance" principle still applies, and
>> -ffp-contract=fast (the current default outside of -std=cNN) 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 =standard without -ffast-math is
> reasonable. IIRC the standard allows such default if it's indicated,
> so it doesn't require =off anywhere.
How much numerical code is compatible with that? For example, David
Goldberg's What Every Computer Scientist Should Know About
Floating-Point Arithmetic (revised) contains this sentence:
| A language definition that does not require parentheses to be honored
| is useless for floating-point calculations.
<https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html>
Few people have access to the IEEE 754 standard, and Goldberg's article
is therefore widely quoted as gospel. If I understand this correctly,
according to Goldberg, contractions make C “useless”. But I'm not a
floating point person, and I nowadays regret that I looked down upon the
numerical methods people at university.
Thanks,
Florian
next prev parent reply other threads:[~2023-09-18 10:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 16:48 Florian Weimer
2023-09-14 17:09 ` Alexander Monakov
2023-09-18 7:50 ` Alexander Monakov
2023-09-18 8:06 ` Richard Biener
2023-09-18 10:10 ` Florian Weimer [this message]
2023-09-18 10:37 ` Richard Biener
2023-09-18 11:37 ` Florian Weimer
2023-09-18 11:12 ` Alexander Monakov
2023-09-18 11:34 ` Florian Weimer
2023-09-18 11:55 ` Alexander Monakov
2023-09-18 16:41 ` Florian Weimer
2023-09-18 17:31 ` Alexander Monakov
2023-09-18 17:39 ` Joseph Myers
2023-09-18 11:26 ` Martin Uecker
2023-09-18 11:32 ` Jakub Jelinek
2023-09-18 11:43 ` Alexander Monakov
2023-09-18 12:13 ` Martin Uecker
2023-09-18 15:38 ` Alexander Monakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877condc69.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=amonakov@ispras.ru \
--cc=gcc@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).