llvm dev - Sep 2016 - defaults for FP contraction [e.g. fused multiply-add]: suggestion and patch to be slightly more aggressive and to make Clang`s optimization settings closer to having the same meaning as when they are given to GCC [at least for "-O3"]

On 09/09/2016 04:31 PM, Stephen Canon wrote:
> Gating this on -Owhatever is dangerous, .  We should simply default to the
pragma “on” state universally.
Why so?  [honestly asking, not arguing]

My guess: b/c we don`t want programs to give different results when compiled at
different
"-O<...>" settings with the exception of "-Ofast".

At any rate, the above change is trivial to apply to my recent proposed patch:
just remove the
"&& (Res.getCodeGenOpts().OptimizationLevel >= 3)" part of
the condition.

Regards,

Abe

Sent from my iPhone
> On Sep 9, 2016, at 6:21 PM, Abe Skolnik <a.skolnik at samsung.com>
wrote:
> 
>> On 09/09/2016 04:31 PM, Stephen Canon wrote:
>> 
>> Gating this on -Owhatever is dangerous, .  We should simply default to
the pragma “on” state universally.
> 
> Why so?  [honestly asking, not arguing]
> 
> My guess: b/c we don`t want programs to give different results when
compiled at different "-O<...>" settings with the exception of
"-Ofast".
Pretty much.  In particular, imagine a user trying to debug an unexpected
floating point result caused by conversion of a*b + c into fma(a, b, c).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160909/7ec0b784/attachment.html>

[Stephen Canon wrote:]
>>> Gating this on -Owhatever is dangerous, .  We should simply default
to the pragma “on” state universally.
[Abe wrote:]
>> Why so?  [honestly asking, not arguing]
>> My guess: b/c we don`t want programs to give different results when
compiled at different "-O<...>" settings with the exception of
"-Ofast".
[Steve Canon wrote:]
> Pretty much.  In particular, imagine a user trying to debug an unexpected
floating point result caused by conversion of a*b + c into fma(a, b, c).

I strongly agree with that philosophy.  I tried arguing that GCC should change
its policy, but
I was rebuffed ["RESOLVED INVALID"].

For reference:   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77515

Regards,

Abe

> On Sep 9, 2016, at 3:27 PM, Steve Canon via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Sep 9, 2016, at 6:21 PM, Abe Skolnik <a.skolnik at samsung.com
<mailto:a.skolnik at samsung.com>> wrote:
> 
>> On 09/09/2016 04:31 PM, Stephen Canon wrote:
>> 
>>> Gating this on -Owhatever is dangerous, .  We should simply default
to the pragma “on” state universally.
>> 
>> Why so?  [honestly asking, not arguing]
>> 
>> My guess: b/c we don`t want programs to give different results when
compiled at different "-O<...>" settings with the exception of
"-Ofast".
> 
> Pretty much.  In particular, imagine a user trying to debug an unexpected
floating point result caused by conversion of a*b + c into fma(a, b, c).
I think that’s unavoidable, because of the way the optimization levels work. 
Even fma contraction is on by default (something I’d like to see), at -O0, we
wouldn't be doing contraction for:

auto x = a*b;
auto y = x+c;

but we would do that at -O2 since we do mem2reg on x.

-Chris

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