[LLVMdev] Poor floating point optimizations?

Alasdair Grant Alasdair.Grant at arm.com
Sun Nov 21 12:53:13 PST 2010


> I'm aware that there are IEEE requirements for floating point. But all
> C/C++
> compilers like GCC or MSVC have unsafe/fast math switches that disable
> all
> problems related to NaN/Inf/+-0/precision etc because in some
> applications those
> are not as important as performance (for example graphics calculation).

Right, but there's a middle ground of "performance with repeatability" where
you want to have a minimal model of FP arithmetic without NaN/Inf/+-0, but at
the same time you don't want numerical results to be sensitive to which
optimizations the compiler happens to do, which will themselves be sensitive
to compiler version, optimization level, structure of source code etc.

> I've found this
> document: http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt

It says

"GCC provides relaxed floating point support through the flags -ffast-math,
-funsafe-math-optimizations, -fhonor-{s}nans, and some other flags that noone
really uses (-ffast-math is all most people know about)...
"Note that if we were to magically make our own C/C++ compilers, we should
definitely default to the equivalent of -ffast-math.  Empirically, this produces
faster and more precise code for GCC"

This seems to be an x86-centric view, i.e. from the fact that on x86
it's faster not to reduce intermediate results to their source-type
precision.  So by relaxing _this particular_ requirement you really do
get results that are "faster and more precise".  On most architectures
this isn't relevant though.

Other "relaxed" optimizations are faster and generally _less_ precise;
some of them gracefully so, but reassociation can be catastrophically
less precise.  And all of them can lead to unrepeatable results, or
situations where two semantically equivalent sources give different
results.  So even within the space of relaxed optimizations, some fine
grained control is useful.

Al

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.





More information about the llvm-dev mailing list