[llvm-dev] 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"]

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sat Sep 10 18:18:13 PDT 2016


On Sep 10, 2016, at 3:33 AM, Steve Canon <scanon at apple.com> 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 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.
> 
> In C, we don't contract (the equivalent of) this unless we're passed fp-contract=fast.  The pragma only licenses contraction within a statement.

Ah ok.  What’s GCC’s policy on this?

> IIRC, the situation in C++ is somewhat different, and the standard allows contraction across statement boundaries, though I don't think we take advantage of it at present.

Is language standard pedanticism what we want to base our policies on?  It’s great to not violate the standard of course, but it would be suboptimal for switching a .c file to .cpp to change its behavior.  I’m not sure which way this cuts on this topic though, or if the cost is worth bearing.

> TLDR: yeah, let's do this.

Nice :-)

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


More information about the llvm-dev mailing list