llvm dev - Mar 2017 - [RFC] FP Contract = fast?

On 15 March 2017 at 14:58, Hal Finkel <hfinkel at anl.gov>
wrote:
> When you reverted  r282259 in 282289, you also reverted the functional fix
> to make the command-line option actually work. Right now it is broken.
> Regardless of what else we do, we should fix this (we should probably
> recommit r282259, with the default flipped, to pick up the fixes).
We should run check-all and the test-suite with it on/fast before
flipping the switch, and make sure that the behaviour Sebastian
encountered is dealt with before this going live, or we'd be breaking
too many test-suites and reverting and reapplying too often.

But I'm certainly in favour of the plan to make it on/fast by default.

> If you were to change your source file to:
>
> #pragma STDC FP_CONTRACT ON
> int foo(float a, float b, float c) { return a*b+c; }
I wasn't aware you needed the pragma for -ffp-contract=on. I assumed
it would enable on all fp-math that the standard allowed (thus maybe
needing some annotation on the operations).

I thought that the pragma was to avoid using the command line argument...

> I'm certainly in favor of this plan. My users generally find our
current
> defaults confusing because it differs from all of our other compilers (GCC
> and vendor compilers), plus it gives poor performance.
Right, I also agree to follow the principle of least surprise, we
should default to "fast". Let's just make sure the infrastructure
isn't going to crumble and do it.

cheers,
--renato

We should default to pragma STDC FP_CONTRACT ON, not ‘fast’.

‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should be opt-in
(like ‘fast-math’ is).

– Steve
> On Mar 15, 2017, at 12:35 PM, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Right, I also agree to follow the principle of least surprise, we
> should default to "fast". Let's just make sure the
infrastructure
> isn't going to crumble and do it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/39917e3e/attachment.html>

On 03/15/2017 11:39 AM, Stephen Canon wrote:
> We should default to pragma STDC FP_CONTRACT ON, not ‘fast’.
>
> ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should 
> be opt-in (like ‘fast-math’ is).
Why? Other compilers default to 'fast', and 'on' does not play
well with
C++ code (where inlining is really important, and so the statement 
boundaries that restrict contraction encourage bad coding style).

  -Hal
>
> – Steve
>
>> On Mar 15, 2017, at 12:35 PM, Renato Golin via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> Right, I also agree to follow the principle of least surprise, we
>> should default to "fast". Let's just make sure the
infrastructure
>> isn't going to crumble and do it.
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/209eaffc/attachment.html>

On 03/15/2017 11:35 AM, Renato Golin wrote:
> On 15 March 2017 at 14:58, Hal Finkel <hfinkel at anl.gov> wrote:
>> When you reverted  r282259 in 282289, you also reverted the functional
fix
>> to make the command-line option actually work. Right now it is broken.
>> Regardless of what else we do, we should fix this (we should probably
>> recommit r282259, with the default flipped, to pick up the fixes).
> We should run check-all and the test-suite with it on/fast before
> flipping the switch, and make sure that the behaviour Sebastian
> encountered is dealt with before this going live, or we'd be breaking
> too many test-suites and reverting and reapplying too often.
>
> But I'm certainly in favour of the plan to make it on/fast by default.
>
>
>> If you were to change your source file to:
>>
>> #pragma STDC FP_CONTRACT ON
>> int foo(float a, float b, float c) { return a*b+c; }
> I wasn't aware you needed the pragma for -ffp-contract=on. I assumed
> it would enable on all fp-math that the standard allowed (thus maybe
> needing some annotation on the operations).
>
> I thought that the pragma was to avoid using the command line argument...
You shouldn't; this is a bug.

  -Hal
>
>
>> I'm certainly in favor of this plan. My users generally find our
current
>> defaults confusing because it differs from all of our other compilers
(GCC
>> and vendor compilers), plus it gives poor performance.
> Right, I also agree to follow the principle of least surprise, we
> should default to "fast". Let's just make sure the
infrastructure
> isn't going to crumble and do it.
>
> cheers,
> --renato
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory