This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop unrolling-related SPEC regressions?
- From: Dale Johannesen <dalej at apple dot com>
- To: Laurent Guerby <guerby at acm dot org>
- Cc: Dale Johannesen <dalej at apple dot com>, Andreas Jaeger <aj at suse dot de>, Paolo Carlini <pcarlini at unitus dot it>, gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: Wed, 6 Feb 2002 14:43:05 -0800
- Subject: Re: Loop unrolling-related SPEC regressions?
On Wednesday, February 6, 2002, at 02:08 PM, Laurent Guerby wrote:
> GCC S G/S SP G/SP
> 164.gzip 461 472 0.976 563 0.818
> 175.vpr 259 255 1.015 285 0.908
> 176.gcc 323 248 1.302 355 0.909
> 181.mcf 180 194 0.927 196 0.918
> 186.crafty 524 632 0.829 678 0.772
> 197.parser 325 372 0.873 373 0.871
> 252.eon 642 692 0.927 1056 0.607
> 253.perlbmk 495 668 0.741 720 0.687
> 254.gap 366 441 0.829 441 0.829
> 255.vortex 410 702 0.584 731 0.560
> 256.bzip2 305 335 0.910 343 0.889
> 300.twolf 284 340 0.835 360 0.788
>
> Apparent weaknesses on base are vortex and perlbmk, has
> anyone looked at them? perl might be interesting, 25%
> base performance hit on such a complex piece of free software,
> there must be some critical interpreter piece of code
> completely miscompiled by CVS GCC (performance-wise).
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.
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 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.