Re: Loop unrolling-related SPEC regressions?

[Jan Hubicka <jh at suse dot cz>]

> 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