This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new benchmark times on alpha
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Subject: Re: new benchmark times on alpha
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sun, 11 Nov 2001 19:49:25 +0100
- Cc: Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org
- References: <20011111145436.A8668@atrey.karlin.mff.cuni.cz> <200111111843.fABIhZm05512@banach.math.purdue.edu>
> > OK, I may take a look at that example.
> >
> > Honza
> > >
> > > The .i file for the most egregious compile-time problems is at
> > >
> > > http://www.math.purdue.edu/~lucier/scheme.i.gz
> > >
> > > Brad Lucier
>
> It seems to be relatively easy to isolate the problem pass here ;-):
>
> popov-15% /export/u10/gcc-3.1/lib/gcc-lib/alphaev6-unknown-linux-gnu/3.1/cc1 -I../../../lib -O2 -W -Wall -Wno-unused -Wdisabled-optimization -fno-math-errno -fno-strict-aliasing -mcpu=ev6 -fomit-frame-pointer scheme.i
> ___H__20_scheme {GC 22338k -> 5849k} {GC 44113k -> 5438k} {GC 8029k -> 5861k} {GC 8882k -> 6508k} {GC 10519k -> 5394k} {GC 7447k -> 5989k} {GC 12330k -> 6716k} ___init_proc ____20_scheme
> Execution times (seconds)
> garbage collection : 0.76 ( 1%) usr 0.02 ( 2%) sys 1.25 ( 1%) wall
> cfg construction : 0.40 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall
> cfg cleanup : 80.13 (76%) usr 0.00 ( 0%) sys 80.00 (75%) wall
Actually in my similar benchmarks the problem seems to be expunge_block call
that do renumber all the blocks. In case function is large and many
blocks are removed, it takes a while to kill process that.
I am not quite sure how to handle it w/o giving up the current scheme of bbs
indexed in program order...
I will take a look at your testcase tomorrow. Thanks!
Honza