Proposal Raised To Deprecate "-Ofast" For The LLVM/Clang Compiler

[phoronix]

Phoronix: Proposal Raised To Deprecate "-Ofast" For The LLVM/Clang Compiler

Some that crave the absolute best possible performance sometimes build their software with the "-Ofast" optimization level that is a step above "-O3" but comes with the risk of potentially unsafe math. LLVM developers are now weighing whether to deprecate -Ofast to either remove it or have it just be an alias for the -O3 optimizations...

https://www.phoronix.com/news/LLVM-Might-Deprecate-Ofast

[Markospox]

Make that an alias and develop -O4 that will optimize more but without errors of that type .

[s_j_newbury]

-Ofast is well known and documented, I frequently use it for packages I know to be safe without IEEE-754 compliance. People get too hung-up on "compliant FP", it's only purpose is to provide a compatible hardware/software definition for some compatibility guarantees, if they really want IEEE-754 they should stick to using the x87 co-processor/execution unit since that's what it is designed to do. Forcing IEEE conformance when it isn't necessary just hamstrings performance for no good reason.

[s_j_newbury]

Make that an alias and develop -O4 that will optimize more but without errors of that type .

They're just user errors though. If you compile code which depends upon IEEE754 behaviour without IEEE754 support, that's on you.

[NotMine999]

They're just user errors though. If you compile code which depends upon IEEE754 behaviour without IEEE754 support, that's on you.

So sometimes 2 + 2 = 5 instead of 2 + 2 = 4 ... so what's the problem with that?

[david-nk]

So sometimes 2 + 2 = 5 instead of 2 + 2 = 4 ... so what's the problem with that?

It's more the opposite. With -Ofast the compiler is allowed to assume that 2 + 2 = 4 instead of having to do the actual floating point math and ending up with 3.9999042 or whatever.

Strict IEEE-754 compliance introduces a few optimization barriers for compilers.
For example, in traditional math the following is true: x/3*3 = x
But not in floating point math, the compiler actually has to do both operations to be compliant.
-Ofast/-ffast-math on the other hand allows it to elide the division and multiplication, so

x/=3.0; x*=3.0;

is a no-op.

[commodore256]

If you're willing to risk unsafe math you might as well use -funsafe-math-optimizations

No, those math optimizations are not simultaneously fun and safe F(orce)Unsafe-math-optimizations

[ms178]

They're just user errors though. If you compile code which depends upon IEEE754 behaviour without IEEE754 support, that's on you.

For someone not familiar with coding or not able to read the code, how am I supposed to know if the code depends on correct IEEE754 behavior? The easy answer is to try it out regardless and see what breaks, but some kind of warning from the dev would be great (glibc does that if you set -Ofast).

[dEnigma]

Maybe just rename it to -Ounsafe or something.

[rene]

the usual modern "just change for the sake of change" it has been there for decades, and software uses it in production. No reason to change to make some students hello world FP math work like in the textbook. If this lands upstream I'll just revert it for our t2 package for high performance optimizations ,-) https://t2sde.org/packages/llvm