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

Wed Jun 30 11:15:17 PDT 2021

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 <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.
[Blower, Melanie] Yes I committed those changes for fprotect-parens today
> >
> > 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.
> 