Re: Concerns regarding the -ffp-contract=fast default

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov <amonakov@ispras.ru> 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=x86-64-v3, I rediscovered
> > > several packages had test suite failures because x86-64 suddenly gained
> > > FMA support.  I say “rediscovered” because these issues 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=off because the
> > > failures did not reproduce on x86-64.  I'm not sure if this is the right
> > > course of action.
> > >
> > > 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.

> > > thing looks suspiciously like a quick hack to get a performance
> > > improvement from FMA instructions (sorry).
> > >
> > > I know that GCC 14 has -fp-contract=standard.  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-/
> >
> > Note that with =standard FMA contraction is still allowed within an
> > expression: the compiler will transform 'x * y + z' to 'fma(x, y, z)'.
> > The difference between =fast and =standard is contraction across
> > statement boundaries. So I'd expect some test suite failures you speak of
> > to remain with =standard as opposed to =off.
> >
> > I think it's better to switch both C and C++ defaults to =standard,
> > 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 =off even)
> >
> > See https://gcc.gnu.org/PR106902 for a worked example where -ffp-contract=fast
> > caused a correctness issue in a widely used FOSS image processing application
> > that was quite hard to debug.
> >
> > Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast 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 default,
> I feel that could be helpful.
>
> One of the tricky aspects is what to do under -std=cNN, which implies
> -ffp-contract=off; "upgrading" it to =standard would introduce FMAs.
>
> Also, I'm a bit unsure what you were implying here:
>
> > I know that GCC 14 has -fp-contract=standard.  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=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.

Richard.

>
> Thanks.
> Alexander