This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Status (2004-08-09)
- From: Diego Novillo <dnovillo at redhat dot com>
- To: mitchell at mail dot codesourcery dot com
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Dorit Naishlos <DORIT at il dot ibm dot com>, David Edelsohn <dje at watson dot ibm dot com>
- Date: Thu, 12 Aug 2004 13:22:09 -0400
- Subject: Re: GCC Status (2004-08-09)
- Organization: Red Hat Canada
- References: <20040809184502.31786.qmail@mail.codesourcery.com>
On Mon, 2004-08-09 at 14:45, mitchell@mail.codesourcery.com wrote:
> Right
> now, Diego's tester is showing us close to GCC 3.3.x on integer and
> floating-point tests -- but well behind GCC 3.1.x and 3.2.x on
> floating-point tests. (Something untoward happened in late July it
> looks like.)
>
Local configuration problem. I fixed it now. But we do seem to have
lost several SPEC marks over the last few days. Not good.
> I'm not too surprised by these results; our new
> optimization infrastructure is groovy, but the RTL optimizers had been
> tuned for a decade, so it will take a while to do substantially
> better.
>
Agreed.
> I'd be interested in impressions from Diego, Jeff Law, RTH,
> etc. on the current state of the optimizers.
>
I have not kept up with LNO as much as I would've wanted. My general
impression is that without some of the loop optimizations, we won't be
able to get above the 3.4 watermark for SPEC. We are hurting
particularly bad in things like perl and crafty.
Now, this may not be significant as a release criteria. We seem to be
doing better in some C++ codes.
Another thing that we still have not completely finished is the
replacement of redundant RTL passes. Part of the problem may be that
they are not 100% redundant. That adds to our compile times and should
probably be addressed before 3.5 goes out the door.
Memory and compile time problems keep coming up. Would it make sense to
set 'better compile-time / memory usage than 3.4' as a release criteria?
Diego.