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

[Kaylor, Andrew via cfe-dev]

The behavior of -fprotect-parens goes in the opposite direction. It provides a way for the user to indicate specific areas of the code where fast-math (specifically reassociation) should not be allowed. Conversely, -fno-protect-parens simply allows the default behavior. I can’t think of a case where the -fprotect-parens flag overrides the explicit behavior of the source code.

We have support in clang for a pragma (‘clang fp <>’) which can enable and disable individual fast-math flags (including contract).

I wouldn’t consider the deviation from GCC to be dangerous in this case since the deviation is just disabling an optimization which isn’t guaranteed to happen anyway.


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Keane, Erich via llvm-dev
Sent: Wednesday, June 30, 2021 1:42 PM
To: Steve (Numerics) Canon <scanon at apple.com>
Cc: llvm-dev at lists.llvm.org; Yaxun Liu <yaxun.liu at amd.com>; cfe-dev at lists.llvm.org; guille at berkeley.edu
Subject: Re: [llvm-dev] fp-contract=fast and pragmas

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

From: Steve (Numerics) Canon <scanon at apple.com<mailto:scanon at apple.com>>
Sent: Wednesday, June 30, 2021 10:40 AM
To: Stephen Canon <scanon at apple.com<mailto:scanon at apple.com>>
Cc: Keane, Erich <erich.keane at intel.com<mailto:erich.keane at intel.com>>; Yaxun Liu <yaxun.liu at amd.com<mailto:yaxun.liu at amd.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>; guille at berkeley.edu<mailto:guille at berkeley.edu>
Subject: Re: [llvm-dev] fp-contract=fast and pragmas

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

On Jun 30, 2021, at 1:34 PM, Steve (Numerics) Canon via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

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.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210630/83430f89/attachment-0001.html>