[llvm-dev] fp-contract=fast and pragmas

[Kaylor, Andrew via llvm-dev]

Hi everyone,

 

I’ve been exploring clang’s fp-contract behavior recently, and I see that when ‘-ffp-contract=fast’ is used it can’t be overridden with a pragma. I would have regarded this as a bug (and in fact, a bug has been filed https://bugs.llvm.org/show_bug.cgi?id=39679). However, I’ve found some discussions on the mailing lists that described this as expected behavior.

 

Last October, Sam Liu added support for a new setting (‘fp-contract=fast-honor-pragmas’) and updated the clang documentation to reflect the behavior of fp-contract=fast. See https://reviews.llvm.org/D90174. I feel very strongly that this should have been done the other way around -- fp-contract=fast should honor pragmas and if we need an option that doesn’t that could be added.

 

In the above review, John McCall asked what “other compilers” do. Steve Canon showed that GCC doesn’t honor the pragma. If I may humbly offer another  “other compiler”, ICC (which doesn’t distinguish between ‘on’ and ‘fast’ for fp-contract) does respect the pragma (https://godbolt.org/z/x5r9WdYb4). I’m not saying that ICC should be treated as a reference implementation over GCC or anything like that, but I am saying that its behavior strikes me as more correct than what GCC or clang currently do.

 

Thoughts and opinions?

 

Thanks,

Andy

 

[John McCall via llvm-dev]

I don’t disagree with you in the abstract, but we consider this a GCC-designed feature. ICC’s value as contrary precedent appears especially weak because, as you point out, they don’t really implement -ffp-contract=fast.

There are plenty of other GCC-designed things that I don’t particularly like the design of, but where we nonetheless consider ourselves bound by their behavior.

John.

[Kaylor, Andrew via llvm-dev]

Hi John,

 

Let me be clarify that ICC-compatibility isn’t my goal here. We can do that out-of-tree for Intel compilers based on LLVM.

 

My motivation is a problem I’m working on with the LLVM test suite. The Polybench benchmarks in the test are currently attempting to use ‘#pragma STDC FP_CONTRACT OFF’ to create a value-safe kernel whose results can be compared against an otherwise identical kernel that is compiled with whatever options the test suite is configured to use. This strategy fails if the test suite is configured to compile with ‘-ffp-contract=fast’. That’s the problem I’m trying to solve by having clang respect the pragma.

 

See https://reviews.llvm.org/D25346, https://reviews.llvm.org/D102861, and https://reviews.llvm.org/D104935.

 

Thanks,

Andy

[Steve (Numerics) Canon via llvm-dev]

It sounds to me like this test is simply incompatible with fp-contract=fast and should not be used in that mode.

– Steve

[Keane, Erich via llvm-dev]

It seems awkward to me that we have a command-line switch that overrides source code to this extent.  Typically our command-line arguments cause us to change ‘defaults’, rarely do they cause us to ignore the source code.  IMO, there is a bit of a natural ‘order’ to where how an option like this should be specified, that is, code overrides command line overrides default.

 

At bare minimum, having a pragma like this that is supported, but just ignored in this case needs to have some level of diagnostic.  Silently ignoring a developer’s preference is the worst thing we can do.

 

From: Steve (Numerics) Canon <sca...@apple.com>
Sent: Wednesday, June 30, 2021 10:20 AM
To: Kaylor, Andrew <andrew...@intel.com>
Cc: John McCall <rjmc...@apple.com>; llvm...@lists.llvm.org; cfe...@lists.llvm.org; Yaxun Liu <yaxu...@amd.com>; Keane, Erich <erich...@intel.com>; Blower, Melanie I <melanie...@intel.com>; Sanjay Patel <spa...@rotateright.com>; Renato Golin <reng...@gmail.com>; Hal Finkel <hal.fin...@gmail.com>; gui...@berkeley.edu; ueno.m...@jp.fujitsu.com; Matthew....@amd.com
Subject: Re: fp-contract=fast and pragmas

 

It sounds to me like this test is simply incompatible with fp-contract=fast and should not be used in that mode.

[Steve (Numerics) Canon via llvm-dev]

Aren’t you all (Intel) the ones promoting -f(no-)protect-parens, which is a command line flag that overrides source code semantics in _exactly_ the same manner?

– Steve

[Keane, Erich via llvm-dev]

I personally am not/have nothing to do with it, but I don’t doubt Intel is doing something like that.

 

The difference is that the flag alters the ‘default’ semantics.  Here, the #pragma ALSO attempts to alter the ‘default’ semantics explicitly, but is ignored. 

[Steve (Numerics) Canon via llvm-dev]

Note that I’m actually pretty sympathetic to this line of argument; compilation-unit scoped flags are too heavy-handed, and pragma and attribute scoping is much nicer. I just think that it’s a much broader change than this one flag and requires a correspondingly broader discussion. E.g. I would expect fast-math to behave identically. It would also, as John noted, introduce a subtle incompatibility with GCC, which would be pretty dangerous.

– Steve

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Keane, Erich via llvm-dev]

I would also expect/hope fast-math to work the same way. 

 

As far as GCC compat, I know we play a little fast/loose with it in other cases, but I can definitely see the danger here.  To me, this feels like “GCC made a bad choice, so we are sticking ourselves with it”.

[John McCall via llvm-dev]

On 30 Jun 2021, at 13:36, Keane, Erich wrote:
> I personally am not/have nothing to do with it, but I don’t doubt
> Intel is doing something like that.
>
> The difference is that the flag alters the ‘default’ semantics.
> Here, the #pragma ALSO attempts to alter the ‘default’ semantics
> explicitly, but is ignored.

Yes, deliberately, because that’s the apparently-intended interaction
by the compiler that introduced those two features. Go convince the GCC
developers that they’re wrong about their feature, and then I’ll
happily sign off on changing Clang’s behavior to match. Otherwise you
might as well be arguing that the “pure” and “const” attributes
are backwards.

John.

>
> From: Steve (Numerics) Canon <sca...@apple.com>
> Sent: Wednesday, June 30, 2021 10:34 AM
> To: Keane, Erich <erich...@intel.com>
> Cc: Kaylor, Andrew <andrew...@intel.com>; John McCall
> <rjmc...@apple.com>; llvm...@lists.llvm.org; cfe...@lists.llvm.org;
> Yaxun Liu <yaxu...@amd.com>; Blower, Melanie I
> <melanie...@intel.com>; Sanjay Patel <spa...@rotateright.com>;
> Renato Golin <reng...@gmail.com>; Hal Finkel
> <hal.fin...@gmail.com>; gui...@berkeley.edu;
> ueno.m...@jp.fujitsu.com; Matthew....@amd.com
> Subject: Re: fp-contract=fast and pragmas
>
> Aren’t you all (Intel) the ones promoting -f(no-)protect-parens,
> which is a command line flag that overrides source code semantics in
> _exactly_ the same manner?
>
>
> – Steve
>
>
>
> On Jun 30, 2021, at 1:30 PM, Keane, Erich

> <erich...@intel.com<mailto:erich...@intel.com>> wrote:
>
> It seems awkward to me that we have a command-line switch that
> overrides source code to this extent. Typically our command-line
> arguments cause us to change ‘defaults’, rarely do they cause us
> to ignore the source code. IMO, there is a bit of a natural
> ‘order’ to where how an option like this should be specified, that
> is, code overrides command line overrides default.
>
> At bare minimum, having a pragma like this that is supported, but just
> ignored in this case needs to have some level of diagnostic. Silently
> ignoring a developer’s preference is the worst thing we can do.
>
> From: Steve (Numerics) Canon
> <sca...@apple.com<mailto:sca...@apple.com>>
> Sent: Wednesday, June 30, 2021 10:20 AM
> To: Kaylor, Andrew

> <andrew...@intel.com<mailto:andrew...@intel.com>>
> Cc: John McCall <rjmc...@apple.com<mailto:rjmc...@apple.com>>;
> llvm...@lists.llvm.org<mailto:llvm...@lists.llvm.org>;
> cfe...@lists.llvm.org<mailto:cfe...@lists.llvm.org>; Yaxun Liu
> <yaxu...@amd.com<mailto:yaxu...@amd.com>>; Keane, Erich
> <erich...@intel.com<mailto:erich...@intel.com>>; Blower, Melanie
> I <melanie...@intel.com<mailto:melanie...@intel.com>>; Sanjay
> Patel <spa...@rotateright.com<mailto:spa...@rotateright.com>>; Renato
> Golin <reng...@gmail.com<mailto:reng...@gmail.com>>; Hal Finkel
> <hal.fin...@gmail.com<mailto:hal.fin...@gmail.com>>;
> gui...@berkeley.edu<mailto:gui...@berkeley.edu>;
> ueno.m...@jp.fujitsu.com<mailto:ueno.m...@jp.fujitsu.com>;
> Matthew....@amd.com<mailto:Matthew....@amd.com>

> Subject: Re: fp-contract=fast and pragmas
>
> It sounds to me like this test is simply incompatible with
> fp-contract=fast and should not be used in that mode.
>
> – Steve
>
>
>
> On Jun 30, 2021, at 11:14 AM, Kaylor, Andrew

> <andrew...@intel.com<mailto:andrew...@intel.com>> wrote:
>
> Hi John,
>
> Let me be clarify that ICC-compatibility isn’t my goal here. We can
> do that out-of-tree for Intel compilers based on LLVM.
>
> My motivation is a problem I’m working on with the LLVM test suite.
> The Polybench benchmarks in the test are currently attempting to use
> ‘#pragma STDC FP_CONTRACT OFF’ to create a value-safe kernel whose
> results can be compared against an otherwise identical kernel that is
> compiled with whatever options the test suite is configured to use.
> This strategy fails if the test suite is configured to compile with
> ‘-ffp-contract=fast’. That’s the problem I’m trying to solve
> by having clang respect the pragma.
>
> See https://reviews.llvm.org/D25346, https://reviews.llvm.org/D102861,
> and https://reviews.llvm.org/D104935.

[Blower, Melanie I via llvm-dev]

Jumping in here, AFAIK gcc doesn't support anything along the lines of #pragma float_control -- is that right?

I thought there is general agreement that source > command-line > default. Surprised to find this isn't universal.

Also a reply about fprotect-parens below

> -----Original Message-----
> From: John McCall <rjmc...@apple.com>
> Sent: Wednesday, June 30, 2021 2:02 PM
> To: Keane, Erich <erich...@intel.com>
> Cc: Steve (Numerics) Canon <sca...@apple.com>; Kaylor, Andrew
> <andrew...@intel.com>; llvm...@lists.llvm.org; cfe...@lists.llvm.org;
> Yaxun Liu <yaxu...@amd.com>; Blower, Melanie I
> <melanie...@intel.com>; Sanjay Patel <spa...@rotateright.com>;
> Renato Golin <reng...@gmail.com>; Hal Finkel
> <hal.fin...@gmail.com>; gui...@berkeley.edu;
> ueno.m...@jp.fujitsu.com; Matthew....@amd.com
> Subject: Re: fp-contract=fast and pragmas
>

> On 30 Jun 2021, at 13:36, Keane, Erich wrote:
> > I personally am not/have nothing to do with it, but I don’t doubt
> > Intel is doing something like that.

[Blower, Melanie] Yes I committed those changes for fprotect-parens today

[Kaylor, Andrew via llvm-dev]

> Yes, deliberately, because that’s the apparently-intended interaction by the compiler that introduced those two features.

Given GCC's history with fp-contract (for example, the fact that it treats fp-contract=on as an alias for fp-contract=off) I think it's difficult to make any confident statements about what is intended. The fact that clang will generate FMA with '-ffp-contract=on' is a bigger (and arguably more "dangerous") deviation from GCC than having clang respect the STDC pragma would be.

I don’t believe GCC implements the "STDC FP_CONTRACT" pragma. Their documentation (https://gcc.gnu.org/onlinedocs/gcc/Floating-point-implementation.html) says they do not. See also, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785

I'll admit there is a bit of ambiguity here. The ISO standard says that "#pragma STDC FP_CONTRACT OFF" should disable FMA, but -ffp-contract=fast allows contraction when the language standard doesn't. Here's the thing though -- putting aside the question of how the contraction mode is set, it is a bug to generate FMA when contraction is disabled, but it is not a bug to not generate FMA instructions when contraction is enabled. So, depending on your expectations, the current behavior may or may not be a bug with respect to the generated code, but the behavior I'm proposing would be conservatively correct.

-----Original Message-----
From: John McCall <rjmc...@apple.com>