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

[Kaylor, Andrew via cfe-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 <rjmccall at apple.com> 
Sent: Wednesday, June 30, 2021 2:02 PM
To: Keane, Erich <erich.keane at intel.com>
Cc: Steve (Numerics) Canon <scanon at apple.com>; Kaylor, Andrew <andrew.kaylor at intel.com>; llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org; Yaxun Liu <yaxun.liu at amd.com>; Blower, Melanie I <melanie.blower at intel.com>; Sanjay Patel <spatel at rotateright.com>; Renato Golin <rengolin at gmail.com>; Hal Finkel <hal.finkel.llvm at gmail.com>; guille at berkeley.edu; ueno.masakazu at jp.fujitsu.com; Matthew.Arsenault at 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.
>
> 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 <scanon at apple.com>
> Sent: Wednesday, June 30, 2021 10:34 AM
> To: Keane, Erich <erich.keane at intel.com>
> Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; John McCall 
> <rjmccall at apple.com>; llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org; 
> Yaxun Liu <yaxun.liu at amd.com>; Blower, Melanie I 
> <melanie.blower at intel.com>; Sanjay Patel <spatel at rotateright.com>; 
> Renato Golin <rengolin at gmail.com>; Hal Finkel 
> <hal.finkel.llvm at gmail.com>; guille at berkeley.edu; 
> ueno.masakazu at jp.fujitsu.com; Matthew.Arsenault at 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.keane at intel.com<mailto:erich.keane at 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
> <scanon at apple.com<mailto:scanon at apple.com>>
> Sent: Wednesday, June 30, 2021 10:20 AM
> To: Kaylor, Andrew
> <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
> Cc: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>>;
> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>;
> cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>; Yaxun Liu 
> <yaxun.liu at amd.com<mailto:yaxun.liu at amd.com>>; Keane, Erich 
> <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Blower, Melanie 
> I <melanie.blower at intel.com<mailto:melanie.blower at intel.com>>; Sanjay 
> Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>>; Renato 
> Golin <rengolin at gmail.com<mailto:rengolin at gmail.com>>; Hal Finkel 
> <hal.finkel.llvm at gmail.com<mailto:hal.finkel.llvm at gmail.com>>;
> guille at berkeley.edu<mailto:guille at berkeley.edu>;
> ueno.masakazu at jp.fujitsu.com<mailto:ueno.masakazu at jp.fujitsu.com>;
> Matthew.Arsenault at amd.com<mailto:Matthew.Arsenault at 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.kaylor at intel.com<mailto:andrew.kaylor at 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.