optimization/4991: gcc 3.x produces worse floating point code on all x86 architectures than 2.95.x

[rwhaley at cs dot utk dot edu]

>Number:         4991
>Category:       optimization
>Synopsis:       gcc 3.x produces worse floating point code on all x86 architectures than 2.95.x
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 03 11:06:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     rwhaley@cs.utk.edu
>Release:        gcc 3.0-3.0.2
>Organization:
>Environment:
gcc installed on any x86.  I show results for Linux/Athlon and Linux/PIII
>Description:
Gcc 3.0 appears to throw in many spurious fxch, which results in slowdown on all x87 architectures (on some archs, such as the PIII, fxch is close to free, but it always eats up instruction decode bandwidth, etc, and it is not free at all on many archs).  For highly tuned floating point code, this poor stack usage causes a 10-20% drop in performance of the 2.95.x stack handling.

The register fetch algorithm gcc uses is good for PentiumX, but really bad for Athlons.  This can cause a 50% drop in register blocked code for Athlons.

Full details are available at:
   http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html

This site gives source code, examples with makefiles, analysis of assembler,etc.

I originally reported this as GNATS c/3913, but was informed that optimization would be a better catagory to submit to (I actually hadn't seen this classification, or I would have submitted here in the first place).  
>How-To-Repeat:
Details are given at
   http://www.cs.utk.edu/~rwhaley/ATLAS/gcc30.html
>Fix:
If there were an option to use the 2.95.x fp register stack optimizer and fetch scheduler, we'd be golden.
>Release-Note:
>Audit-Trail:
>Unformatted: