[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
Thu Aug 10 06:52:00 GMT 2006
------- 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
More information about the Gcc-bugs
mailing list