[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

["paolo dot bonzini at lu dot unisi dot ch" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #59 from paolo dot bonzini at lu dot unisi dot ch  2006-08-10 06:52 -------
Subject: Re:  [4.0/4.1 Regression] gcc 4 produces worse
 x87 code on all platforms than gcc 3


> Thanks for the response, but I believe you are conflating two issues (as is
> this flag, which is why this is bad news).  Different answers to the question
> "what is this sum" does not ruin IEEE compliance.  I am referring to IEEE 754,
> which is a standard set of rules for storage and arithmetic for floating point
> (fp) on modern hardware.
You are also confusing -funsafe-math-optimizations with -ffast-math.  
The latter is a "one catch all" flag that compiles as if there were no 
FP traps, infinities, NaNs, and so on.  The former instead enables 
"unsafe" optimizations but not "catastrophic" optimizations -- if you 
consider meaningless results on badly conditioned matrixes to not be 
catastrophic...

A more or less complete list of things enabled by 
-funsafe-math-optimizations includes:

Reassociation:
- reassociation of operations, not only for the vectorizer's sake but 
also in the unroller (see around line 1600 of loop-unroll.c)
- other simplifications like a/(b*c) for a/b/c
- expansion of pow (a, b) to multiplications if b is integer

Compile-time evaluation:
- doing more aggressive compile-time evaluation of floating-point 
expressions (e.g. cabs)
- less accurate modeling of overflow in compile-time expressions, for 
formats such as 106-bit mantissa long doubles

Math identities:
- expansion of cabs to sqrt (a*a + b*b)
- simplifications involving trascendental functions, e.g. exp (0.5*x) 
for sqrt (exp (x)), or x for tan(atan(x))
- moving terms to the other side of a comparison, e.g. a > 4 for a + 4 > 
8, or x > -1 for 1 - x < 2
- assuming in-domain arguments of sqrt, log, etc., e.g. x for 
sqrt(x)*sqrt(x)
- in turn, this enables removing math functions from comparisons, e.g. x 
 > 4 for sqrt (x) > 2

Optimization:
- strength reduction of a/b to a*(1/b), both as loop invariants and in 
code like vector normalization
- eliminating recursion for "accumulator"-like functions, i.e. f (n) = n 
+ f(n-1)

Back-end operation:
- using x87 builtins for transcendental functions

There may be bugs, but in general these optimizations are safe for 
infinities and NaNs, but not for signed zeros or (as I said) for very 
badly conditioned data.
> I am unaware of their being any rules on compilation.
>   
Rules are determined by the language standards.  I believe that C 
mandates no reassociation; Fortran allows reassociation unless explicit 
parentheses are present in the source, but this is not (yet) implemented 
by GCC.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827