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

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

[zack]

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

State-Changed-From-To: open->closed
State-Changed-By: zack
State-Changed-When: Tue Feb 26 17:20:05 2002
State-Changed-Why:
    Reporter indicates problem has been solved in 3.1.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4991

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

[Zack Weinberg]

The following reply was made to PR optimization/4991; it has been noted by GNATS.

From: Zack Weinberg <zack@codesourcery.com>
To: rwhaley@cs.utk.edu
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: optimization/4991: gcc 3.x produces worse floating point code on all x86 architectures than 2.95.x
Date: Sun, 24 Feb 2002 18:33:56 -0800

 A fair amount of work went into improving x86 scheduler tuning between
 3.0 and 3.1-to-be.  Would it be possible for you to repeat your tests
 with a development snapshot?
 
 zw

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

[rwhaley]

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