This is the mail archive of the
mailing list for the GCC project.
Re: Loop unrolling-related SPEC regressions?
- From: Andreas Jaeger <aj at suse dot de>
- To: Dale Johannesen <dalej at apple dot com>
- Cc: Laurent Guerby <guerby at acm dot org>,Paolo Carlini <pcarlini at unitus dot it>, gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: Thu, 07 Feb 2002 00:00:03 +0100
- Subject: Re: Loop unrolling-related SPEC regressions?
- References: <E2995D70-1B52-11D6-826C-003065C86F94@apple.com>
Dale Johannesen <firstname.lastname@example.org> writes:
> 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.
AFAIK the infrastructure is there, it only needs to be used for
inlining - and also in the new register allocator. Michal, is this
> crafty is heavily dependent on efficiency of "long long".
> It's a chess program, full of 64-bit bitmasks.
> 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.
The inline change brought in August by Kurt Garloff brought a real
performance improvement, check my graphs at http://www.suse.de/~aj/SPEC
> 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.
> vortex accesses a huge amount of virtual memory. Good
> malloc/free performance is critical.
SuSE Labs email@example.com