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

[Alexander Monakov <amonakov@ispras.ru>]

[-- Attachment #1: Type: text/plain, Size: 2955 bytes --]

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

Thanks.
Alexander