* Concerns regarding the -ffp-contract=fast default @ 2023-09-14 16:48 Florian Weimer 2023-09-14 17:09 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2023-09-14 16:48 UTC (permalink / raw) To: gcc 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-/ Thanks, Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-14 16:48 Concerns regarding the -ffp-contract=fast default Florian Weimer @ 2023-09-14 17:09 ` Alexander Monakov 2023-09-18 7:50 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-14 17:09 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc [-- Attachment #1: Type: text/plain, Size: 2000 bytes --] 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. Thanks. Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-14 17:09 ` Alexander Monakov @ 2023-09-18 7:50 ` Alexander Monakov 2023-09-18 8:06 ` Richard Biener 0 siblings, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 7:50 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 7:50 ` Alexander Monakov @ 2023-09-18 8:06 ` Richard Biener 2023-09-18 10:10 ` Florian Weimer 2023-09-18 11:26 ` Martin Uecker 0 siblings, 2 replies; 18+ messages in thread From: Richard Biener @ 2023-09-18 8:06 UTC (permalink / raw) To: Alexander Monakov; +Cc: Florian Weimer, gcc 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 8:06 ` Richard Biener @ 2023-09-18 10:10 ` Florian Weimer 2023-09-18 10:37 ` Richard Biener 2023-09-18 11:12 ` Alexander Monakov 2023-09-18 11:26 ` Martin Uecker 1 sibling, 2 replies; 18+ messages in thread From: Florian Weimer @ 2023-09-18 10:10 UTC (permalink / raw) To: Richard Biener; +Cc: Alexander Monakov, gcc * 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 10:10 ` Florian Weimer @ 2023-09-18 10:37 ` Richard Biener 2023-09-18 11:37 ` Florian Weimer 2023-09-18 11:12 ` Alexander Monakov 1 sibling, 1 reply; 18+ messages in thread From: Richard Biener @ 2023-09-18 10:37 UTC (permalink / raw) To: Florian Weimer; +Cc: Alexander Monakov, gcc On Mon, Sep 18, 2023 at 12:10 PM Florian Weimer <fweimer@redhat.com> wrote: > > * 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> I suppose that applies to re-association not honoring parens. With C you either have no re-association (fine) or re-association but globally, at the expense of violating the standard. FP contraction is _not_ about honoring parens, the 'error' introduced by is subtle. Fortran for example allows re-association by default, but honors parens. GCC can do this just fine. > 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. No, I don't think it says that. Fortran also allows contraction (but not across parens). Richard. > Thanks, > Florian > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 10:37 ` Richard Biener @ 2023-09-18 11:37 ` Florian Weimer 0 siblings, 0 replies; 18+ messages in thread From: Florian Weimer @ 2023-09-18 11:37 UTC (permalink / raw) To: Richard Biener; +Cc: Alexander Monakov, gcc * Richard Biener: >> 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> > > I suppose that applies to re-association not honoring parens. With C > you either have no re-association (fine) or re-association but globally, > at the expense of violating the standard. FP contraction is _not_ > about honoring parens, the 'error' introduced by is subtle. But for contracted expressions, + *is* associative. Maybe this is not the most relevant part of the article for contractions, though. > Fortran for example allows re-association by default, but honors > parens. GCC can do this just fine. I think it's still a divergence from the model promoted by the article. For further problems see “Pitfalls in Computations on Extended-Based Systems”; that covers the matter of excess precision (which, as far as I understand, is very relevant to contractions). It quotes this code snippet: | if (1.0 + x .eq. 1.0) then The C11 standard does not define what “floating expressions” are (as far as I can see), so it's a bit unclear whether the whole thing can be contracted (assuming x is not a NaN). Thanks, Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 10:10 ` Florian Weimer 2023-09-18 10:37 ` Richard Biener @ 2023-09-18 11:12 ` Alexander Monakov 2023-09-18 11:34 ` Florian Weimer 1 sibling, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 11:12 UTC (permalink / raw) To: Florian Weimer; +Cc: Richard Biener, gcc On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > 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. Sorry, do you mean contracting 'x + x - x' to 'x'? That is not allowed due to different result and lack of FP exception for infinities. Contracting 'x + x - x' to fma(x, 2, -x) would be fine. Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:12 ` Alexander Monakov @ 2023-09-18 11:34 ` Florian Weimer 2023-09-18 11:55 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2023-09-18 11:34 UTC (permalink / raw) To: Alexander Monakov; +Cc: Richard Biener, gcc * Alexander Monakov: > On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > >> 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. > > Sorry, do you mean contracting 'x + x - x' to 'x'? Yes. > That is not allowed due to different result and lack of FP exception > for infinities. FP exceptions do not need to preserved in C11 (it's a recommended practice in Annex F only, and the main text explicitly allows changes). But you are right that inf - inf would result in a NaN, so that's a different result that cannot be explained by infinite intermediate precision. Huh, so it's a bad example. Sorry! But the contraction would still be valid after an isfinite check (something that ranger might catch these days), or with with -ffinite-math-only in general. Right? > Contracting 'x + x - x' to fma(x, 2, -x) would be fine. It still changes the result, doesn't it? Thanks, Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:34 ` Florian Weimer @ 2023-09-18 11:55 ` Alexander Monakov 2023-09-18 16:41 ` Florian Weimer 0 siblings, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 11:55 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote: > But the contraction would still be valid after an isfinite check > (something that ranger might catch these days), or with with > -ffinite-math-only in general. Right? Nope, still not valid for negative zero ('x + x - x' would yield positive zero in the default rounding mode). > > Contracting 'x + x - x' to fma(x, 2, -x) would be fine. > > It still changes the result, doesn't it? I don't follow. I doesn't change the result for infinities (produces a NaN). It changes the result when x is so large that 'x + x' is not representable (exponent would overflow), but that's exactly what contraction is about? Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:55 ` Alexander Monakov @ 2023-09-18 16:41 ` Florian Weimer 2023-09-18 17:31 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Florian Weimer @ 2023-09-18 16:41 UTC (permalink / raw) To: Alexander Monakov; +Cc: gcc * Alexander Monakov: >> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine. >> >> It still changes the result, doesn't it? > > I don't follow. I doesn't change the result for infinities (produces > a NaN). It changes the result when x is so large that 'x + x' is > not representable (exponent would overflow), but that's exactly what > contraction is about? Okay, you meant “changing the result” as in “changing the result in a permitted way”. Sorry, was confused. So this is a bad example all around. Are there better ones (that don't involve FMA)? Thanks, Florian ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 16:41 ` Florian Weimer @ 2023-09-18 17:31 ` Alexander Monakov 2023-09-18 17:39 ` Joseph Myers 0 siblings, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 17:31 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc [-- Attachment #1: Type: text/plain, Size: 631 bytes --] On Mon, 18 Sep 2023, Florian Weimer wrote: > Okay, you meant “changing the result” as in “changing the result in a > permitted way”. Sorry, was confused. So this is a bad example all > around. Are there better ones (that don't involve FMA)? If you're looking for something similar to your original example, I can suggest 'x + x + x + x' -> '4 * x' under -frounding-math (i.e. not assuming default rounding mode) or 'x + x + x + x + x + x' -> '6 * x' for default rounding. I don't have a "somewhat practical" example off-hand, since apart from FMA fused operations are rarely available in instruction sets. Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 17:31 ` Alexander Monakov @ 2023-09-18 17:39 ` Joseph Myers 0 siblings, 0 replies; 18+ messages in thread From: Joseph Myers @ 2023-09-18 17:39 UTC (permalink / raw) To: Alexander Monakov; +Cc: Florian Weimer, gcc [-- Attachment #1: Type: text/plain, Size: 1067 bytes --] On Mon, 18 Sep 2023, Alexander Monakov wrote: > > On Mon, 18 Sep 2023, Florian Weimer wrote: > > > Okay, you meant “changing the result” as in “changing the result in a > > permitted way”. Sorry, was confused. So this is a bad example all > > around. Are there better ones (that don't involve FMA)? > > If you're looking for something similar to your original example, I can > suggest 'x + x + x + x' -> '4 * x' under -frounding-math (i.e. not assuming > default rounding mode) or 'x + x + x + x + x + x' -> '6 * x' for default > rounding. > > I don't have a "somewhat practical" example off-hand, since apart from FMA > fused operations are rarely available in instruction sets. Apart from FMA, there are the formatOf operations such as fadd (add two doubles, rounding the result just once to float). Fewer instruction sets have those than have FMA, however (ia64 did; newer versions of Power support such operations as well to some extent, though with limitations when underflow or overflow occur). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 8:06 ` Richard Biener 2023-09-18 10:10 ` Florian Weimer @ 2023-09-18 11:26 ` Martin Uecker 2023-09-18 11:32 ` Jakub Jelinek 1 sibling, 1 reply; 18+ messages in thread From: Martin Uecker @ 2023-09-18 11:26 UTC (permalink / raw) To: Richard Biener, Alexander Monakov; +Cc: Florian Weimer, gcc Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc: > 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. The C standard requires a pragma to turn control it on and off, which GCC does not support. The default is then implementation defined. Martin ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:26 ` Martin Uecker @ 2023-09-18 11:32 ` Jakub Jelinek 2023-09-18 11:43 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Jakub Jelinek @ 2023-09-18 11:32 UTC (permalink / raw) To: Martin Uecker; +Cc: Richard Biener, Alexander Monakov, Florian Weimer, gcc On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote: > > 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. > > The C standard requires a pragma to turn control it on and off, > which GCC does not support. The default is then implementation > defined. Perhaps we should add some initial hammer approach for the pragma, like if you ever use the pragma to turn it somewhere off, it is turned off globally, or ditto per function. Might be far easier than trying to make it precise that contraction is allowed in this expression and not in this subexpression of that etc. Of course, making it precise is the ultimate goal. Jakub ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:32 ` Jakub Jelinek @ 2023-09-18 11:43 ` Alexander Monakov 2023-09-18 12:13 ` Martin Uecker 0 siblings, 1 reply; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 11:43 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Martin Uecker, Richard Biener, Florian Weimer, gcc On Mon, 18 Sep 2023, Jakub Jelinek wrote: > Perhaps we should add some initial hammer approach for the pragma, like > if you ever use the pragma to turn it somewhere off, it is turned off > globally, or ditto per function. Might be far easier than trying to > make it precise that contraction is allowed in this expression and not in > this subexpression of that etc. Of course, making it precise is the > ultimate goal. When implementing -ffp-contract=standard I looked into implementing the pragma (in a precise manner) and I didn't get the impression it would be hard to implement for C. But I was somewhat discouraged by the lack of front-end maintainers reaction to the patch implementing the =standard, so I didn't pursue that. The hardest part would be popping the pragma state when leaving a block, which didn't seem difficult (at least for C). Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 11:43 ` Alexander Monakov @ 2023-09-18 12:13 ` Martin Uecker 2023-09-18 15:38 ` Alexander Monakov 0 siblings, 1 reply; 18+ messages in thread From: Martin Uecker @ 2023-09-18 12:13 UTC (permalink / raw) To: Alexander Monakov, Jakub Jelinek; +Cc: Richard Biener, Florian Weimer, gcc Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov: > On Mon, 18 Sep 2023, Jakub Jelinek wrote: > > > Perhaps we should add some initial hammer approach for the pragma, like > > if you ever use the pragma to turn it somewhere off, it is turned off > > globally, or ditto per function. I think the default should be off - at least for code that does not contain the pragma anywhere. > > Might be far easier than trying to > > make it precise that contraction is allowed in this expression and not in > > this subexpression of that etc. Of course, making it precise is the > > ultimate goal. > > When implementing -ffp-contract=standard I looked into implementing the > pragma (in a precise manner) and I didn't get the impression it would be > hard to implement for C. But I was somewhat discouraged by the lack of > front-end maintainers reaction to the patch implementing the =standard, > so I didn't pursue that. > > The hardest part would be popping the pragma state when leaving a block, > which didn't seem difficult (at least for C). It is fairly restricted where it can appear, it essentially operates on the level of compound statements (!= blocks). Martin ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Concerns regarding the -ffp-contract=fast default 2023-09-18 12:13 ` Martin Uecker @ 2023-09-18 15:38 ` Alexander Monakov 0 siblings, 0 replies; 18+ messages in thread From: Alexander Monakov @ 2023-09-18 15:38 UTC (permalink / raw) To: Martin Uecker; +Cc: Jakub Jelinek, Florian Weimer, gcc On Mon, 18 Sep 2023, Martin Uecker wrote: > > The hardest part would be popping the pragma state when leaving a block, > > which didn't seem difficult (at least for C). > > It is fairly restricted where it can appear, it essentially operates > on the level of compound statements (!= blocks). Thanks for the clarification. Let me note that the standard somehow decided to make out-of-place pragma a (compile-time) UB rather than a constraint violation, leaving us free to make it work for blocks (or launch Nethack). Alexander ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2023-09-18 17:39 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-14 16:48 Concerns regarding the -ffp-contract=fast default 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 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
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).