llvm dev - Nov 2010 - [LLVMdev] Poor floating point optimizations?

Hi Bob,
> For example expressions like "1+x+1+x+1+x+1+x" (basically adding
a lot of
> constants and variables) are complied to a long series off<add>s both
in IR
> and
> assembly code.
> Both GCC and MSVC generates C1*x +C2 (mov + mul + add).
>
> I am new to using LLVM. I am using Visual Studio 2008 on Windows, targeting
> 32-bit X86 code. I'm using LLVM as a library. I've
> added setOptLevel(CodeGenOpt::Aggressive) to the engine but with no effect.
> Please let me know if there are some optimization options/passes in LLVM
that
> could optimize such example expressions as  "1+x+1+x+1+x+1+x".
the reassociate pass deliberately does not perform this kind of optimization
because it is not right to do so if strict floating point correctness is
required.  Probably it should do it if the user supplied an "unsafe
math"
flag.  There's actually a plan to add an "unsafe math" flag to
each fp
operation in the IR, so this setting can be per-operation, but it didn't
happen yet.

Ciao,

Duncan.

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). 

But as I understand, LLVM currently does not have such unsafe/fast math 
optimizations built in and support of such is yet being planned?
I've found this 
document: http://nondot.org/sabre/LLVMNotes/FloatingPointChanges.txt but I 
suppose it was not implemented yet?

Bob

> 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.