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

["whaley at cs dot utsa dot edu" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #62 from whaley at cs dot utsa dot edu  2006-08-10 15:15 -------
Paolo,

>The IEEE standard mandates particular rules for performing operations on
>infinities, NaNs, signed zeros, denormals, ...  The C standard, by
>mandating no reassociation, ensures that you don't mess with NaNs,
>infinities, and signed zeros.  As soon as you perform reassociation,
>there is *no way* you can be sure that you get IEEE-compliant math.

No, again this is a conflation of the issues.  You have IEEE-compliant math,
but the differing orderings provide different summations of those values.  It
is a ANSI/ISO C rule being violated, not an IEEE.  Each individual operation is
IEEE, and therefore both results are IEEE-compliant, but since the C rule
requiring order has been broken, some codes will break.  However, they break
not because of a violation of IEEE, but because of a violation of ANSI/ISO C. 
I can certify whether my code can take this violation of ANSI/ISO C by
examining my code.  I cannot certify my code works w/o IEEE by examining it,
since that means a+b is now essentially undefined.

>http://citeseer.ist.psu.edu/589698.html is an example of a paper that
>shows FP code that avoids accuracy problems.  Any kind of reassociation
>will break that code, and lower its accuracy.  That's why reassociation
>is an "unsafe" math optimization.

Please note I never argued it is was safe.  Violating the C usage rules is
always unsafe.  However, as explained above, I can certify my code for
reordering by examination, but nothing helps an IEEE violation.  My problem is
lumping in IEEE violations (such as 3dNow vectorization, or turning on non-IEEE
mode in SSE) with C violations.

>If you want a -freassociate-fp math, open an enhancement PR and somebody

Ah, you mean like I asked about in end of 2nd paragraph of Comment #56?

>might be more than happy to separate reassociation from the other
>effects of -funsafe-math-optimizations.

What I'm arguing for is not lumping in violations of ISO/ANSI C with IEEE
violations, but you are right that this would fix my particular case.  From
what I see, -funsafe ought to be redefined as violating ANSI/ISO alone, and not
mention IEEE at all.

>(Independent of this, you should also open a separate PR for ATLAS
>vectorization, because that would not be a regression and would not be
>on x87) :-)

You mean like I pleaded for in the last paragraph of Comment #38, but
reluctantly shoved in here because that's what people seemed to want? :)

Thanks,
Clint


-- 


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