[llvm-dev] [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

Abe Skolnik via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 26 08:39:30 PDT 2016


[Abe wrote in an earlier msg.:]

>> Some people -- my team included -- want Clang to remain competitive with GCC
>> and for Clang to gain ground where possible without breaking correct/valid code.

[Renato wrote:]

> That's hard to keep when we're breaking FP contracts. ;)
[...]
> Adding that to -ffast-math wouldn't have been so bad, and I think that's
> a fair game. But no-fast-math O3 should still have a strict FP contract, IMHO.


I agree.  That`s at least the main reason why my first choice was to try to convince the GCC 
people to make GCC less aggressive, FP-wise.  By myself, I was unable to convince the relevant 
people of such a suggestion. [<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77515>]  Therefor, 
I started on the work that resulted in the patch under discussion in this thread.

If anybody reading this has influence over the decisions made in the GCC community, by all 
means please try to convince them that fusing should be _off_ by default and enabled only by 
"-ffast-math", "-ffp-contract=fast", "-Ofast", and maybe also {"-O<x>" where x>3} if there is 
[still?] any such thing in GCC.  [IIRC GCC-for-SPARC at least used to have a meaningful "-O4", 
but that might be "ancient history" by now.]

I think a discussion could be had about how "correct/valid" are programs that break [e.g. 
regression tests fail] when the only change was that the FP results became _more_ accurate.


[Renato wrote:]

> By making it faster in one arch, you may be destroying performance in another,
>  and we really don't want that to happen.

Of course not.


> I think even non-compiler-savvy programmers knows about -ffast-math.

I think "-Ofast" is more clear/obvious, but since Clang already has that and since [AFAIK] 
Clang`s implementation of "-ffast-math" enables FP fusion on all FP-fusion-capable targets, I 
don`t see that any change needs to be made along that particular dimension.

Regards,

Abe



* note to non-{Abe|Renato} readers: Renato is offline/infrequent-email-checking for travel 
reasons for about a week.


More information about the llvm-dev mailing list