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

Steve (Numerics) Canon via llvm-dev
Wed, 30 Jun 2021 17:39:53 -0000

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> 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/D25346>, https://reviews.llvm.org/D102861
<https://reviews.llvm.org/D102861>, and https://reviews.llvm.org/D104935
<https://reviews.llvm.org/D104935>.
>
> _______________________________________________
> LLVM Developers mailing list
> 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/llvm-dev/attachments/20210630/52f8062f/attachment.html>