public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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


  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).