From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13165 invoked by alias); 7 Feb 2002 11:47:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13033 invoked from network); 7 Feb 2002 11:47:03 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 7 Feb 2002 11:47:03 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id MAA00950; Thu, 7 Feb 2002 12:46:45 +0100 Date: Thu, 07 Feb 2002 03:48:00 -0000 From: Jan Hubicka To: Dale Johannesen Cc: Laurent Guerby , Andreas Jaeger , Paolo Carlini , gcc@gcc.gnu.org, rth@redhat.com Subject: Re: Loop unrolling-related SPEC regressions? Message-ID: <20020207114645.GH26252@atrey.karlin.mff.cuni.cz> References: <3C61A96C.7030604@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.24i X-SW-Source: 2002-02/txt/msg00518.txt.bz2 > I looked at Spec quite a bit for my last job and I can > suggest some things that are important. > > Intelligent use of profiling info from the first pass is > important. You'll see the published numbers do this. > Last time I looked gcc used this only for branch > straightening; it can also be used effectively to > drive inlining and register allocation. I did quite active development on this. In 3.1 gcc can do some of optimizations based on profile info, like register allocation. On the cfg-branch we are still focusing on this path for 3.2 timeframe. > > crafty is heavily dependent on efficiency of "long long". > It's a chess program, full of 64-bit bitmasks. This is actually big problem for gcc. It may be workaroundable by using SSE/MMX arithmetics when available. > > eon is the only one in C++. If there are any problems > in exception handling they will show up here. The program > does not actually throw any exceptions, so turning off > the handling for peak may help (SPEC won't let you turn > it off for base). Good inlining decisions are also important. Yes, eon basically appears to be very huge, so everything that shrinks the footprint is usefull. > > the two most heavily executed functions in perl are big; > IME register allocation & scheduling don't always work > well for big functions. They also both call setjmp; if > this disables any substantial amount of optimization it > will hurt. Our setjmp handling should be aggressive enought. We represent it as abnormal edge in the CFG and this optimize the rest of function w/o much of degradation. Honza