[LLVMdev] Poor floating point optimizations?

[Alasdair Grant]

To do FP optimization correctly the compiler needs quite detailed knowledge
of the FP model, that goes beyond just "safe/unsafe".

For example as Chris pointed out, x + 0.0 -> x is not a valid rewrite if
the FP model has signed zeroes (i.e. zeroes whose sign is observable by
well-defined operations in the language).  It is valid in Standard C because
the sign of zero is not observable in Standard C.  On the other hand
your example needs reassociation, to change 1 + x + 1 to x + (1 + 1),
and reassociation generally isn't valid even in Standard C, because it
changes the numeric value of the result.

Other examples: to optimize away a voided computation you need to know
"does the FP model trap or set cumulative exception bits".  To rewrite
x + y as y + x you need to know "does the FP model trap".  There are other
optimizations whose validity depends on whether the rounding mode can be
changed at runtime.

Overall the FP model needs to be able to answer at least these queries:

  - does it trap (i.e. invoke user-defined trap handler with the original
    operands in the original order)
  - does it set cumulative exception bits
  - can the rounding mode be changed at runtime
  - does it have Inf and NaN
  - are denormals flushed to zero (and if so how)

Some of the flags tend to imply others, e.g. you don't in practice have the
ability to trap without the ability to set cumulative exception bits.
To support Standard C/C++ you only need a minimal model; to claim full
IEEE support you need pretty much everything.  The "Java numerics" model
is somewhere in between.

All of these are within the space of "safe" models, the difference is the
set of values and observable events.

As well as this you have a concept of "unsafe" (or "fast") modes which aren't
really models at all - they are modes where the compiler doesn't implement a
well-defined predictable model of FP arithmetic and where numeric results can
vary between different optimization levels, different programming styles (e.g.
inline functions vs. macros) and from one day's build of the compiler to the next.

And within the space of fast modes there are some choices for varying the
heuristics - e.g. replacing division-by-constant by multiply-by-reciprocal
is generally numerically "safer" than reassociation.

At the very least (I believe) a compiler for serious FP work needs a
fast/unsafe mode, a minimal Standard C mode, and an IEEE mode.  Attaching
a safe/unsafe bit to each FP operation is only sufficient if there is only
one safe model in effect at any time.  Even then, exactly what the safe
model is, ought to be configurable.

Al


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Sdadsda Sdasdaas
> Sent: 21 November 2010 00:08
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Poor floating point optimizations?
>
> Thanks for replying so fast. This UnsafeFPMath trick in fact solves
> "pxor adds"
> case, but the resulting code is still not as good as I expected from
> LLVM.
>
> 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".
>
> Bob
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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