From owner-freebsd-chat  Sun Mar  2 18:42:20 1997
Return-Path: <owner-chat>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id SAA22487
          for chat-outgoing; Sun, 2 Mar 1997 18:42:20 -0800 (PST)
Received: from hamby1 (hamby1.lightside.net [207.67.176.17])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id SAA22480
          for <freebsd-chat@FreeBSD.ORG>; Sun, 2 Mar 1997 18:42:16 -0800 (PST)
Received: (from jehamby@localhost)
        by hamby1 (SMI-8.6/SMI-SVR4) id SAA01253;
        Sun, 2 Mar 1997 18:42:56 -0800
Date: Sun, 2 Mar 1997 18:42:56 -0800
From: jehamby@lightside.com (Jake Hamby)
Message-Id: <199703030242.SAA01253@hamby1>
To: henrich@crh.cl.msu.edu, freebsd-chat@FreeBSD.ORG, ghelmer@cs.iastate.edu
Subject: Re: RSA 56-bit key challenge
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: qr3XxXhcXDk9a7SD8Xf6JQ==
Sender: owner-chat@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Guy Helmer writes:
> On Sun, 2 Mar 1997, Charles Henrich wrote:
> 
> > The binary distribution client performs 346534 keys/sec on my PPro/233
> > 
> > A GCC-2.6.3 binary performs 390k/sec on a PPro/233 with HAVE_FPU math libs
> > A GCC-2.7.2 binary performs 219k/sec on a PPro/233 with HAVE_FPU math libs
> 
> That might help explain some of the differences in numbers for my runs of
> SPEC95 fp benchmarks on 2.1.5 (-O2 optimization) w/o HAVE_FPU math libs
> vs. 2.2-BETA (-O4 optimization) w/ HAVE_FPU.  I ran a few of the fp
> benchmarks on 2.2 to compare to my full run under 2.1.5 and found the
> codes ran from slightly faster to much slower under 2.2.  I figured it was
> due to the different math library, but maybe the compiler is more at fault
> than I thought... 

Maybe this has to do with the patch in 2.7.2.1 to disable certain kinds of 
strength reduction (-fstrength-reduce) because of buggy code generation.  Recall 
that this bug was why FreeBSD changed from using -O2 to -O optimization 
(although some people used "-O2 -fno-strength-reduce).  Here's a quote from 
David S. Miller, from the "Sun vs. GCC" thread last month:

>   Also, the various optimizer bugs in GCC in the past have led people
>   to be wary to use -O2 optimization, much less try additional
>   optimization flags.
>
>I know about them, just about all of them are in the strength
>reduction pass.  I am very familiar with the problematic bugs this
>layer has, and I have been actively trying to get people on the GCC
>development team to fix them.  Almost all of these problems have to do
>with when a pointer comparison is converted into an integer invariant
>comparison, and vice versa.  GCC in certain circumstances does not
>notice the change in signed'ness and thus produces incorrect code.  In
>gcc-2.7.2.1, the strength reduction transformations that were known to
>lead to this situation were disabled entirely and in fact this fix was
>the entire reason for that release of gcc.

-- Jake