This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/6007: cfg cleanup tremendous performance hog with -O1
- From: Jan Hubicka <jh at suse dot cz>
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Cc: Jan Hubicka <jh at suse dot cz>, David Edelsohn <dje at watson dot ibm dot com>, gcc at gcc dot gnu dot org, mark at codesourcery dot com, feeley at iro dot umontreal dot ca
- Date: Fri, 29 Mar 2002 17:10:04 +0100
- Subject: Re: optimization/6007: cfg cleanup tremendous performance hog with -O1
- References: <20020328120307.GF27534@atrey.karlin.mff.cuni.cz> <200203282222.g2SMMAL21768@banach.math.purdue.edu>
> >
> > > [RE: crossjumping]
> > >
> > > > I will try to check whether I can squeze out some more cycles or
> > > > find way how to limit this.
> > >
> > > My code uses a lot of computed goto's, with many labels. Is crossjumping
> > > possibly a win in this case? Can it ignore these jumps?
> > >
> > > Brad
> > Hi, here is patch I made as a test. It simply disables crossjumping
> > if there is moer than 100 outgoing edges. Unfortunately I can't benchmark
> > your testcase as my machine runs out of space before getting there. Can you
> > check if this solves your problem? If so, I will prepare more polished
> > version of this patch.
>
> Here is a progress report.
>
> Today's CVS version of gcc-3.1 had a good bootstrap with your patch.
> I'll run the regression tests later.
>
> I'm running the new gcc on my test case now. So far, it's taken
> > 30 minutes of CPU time on my 500 MHz UltraSPARC. Unfortunately,
> it's also taking about 4 GB of swap space, and competing with another
> 400 MB job, so it's not making much progress right now.
>
> The amount of swap necessary is a problem, even if cross-jumping is
> disabled for certain blocks because the number of outgoing edges
> is too large. I've been having memory problems compiling much smaller
> programs on my PII linux box at home because I have "only" 768 MB of
> swap space.
Do you have any idea where the memory consumption come from?
I will try to check, but I am somewhat overload at the moment :(
>
> Is there some way to not build these large internal structures if we don't
> end up using them?
Well, this is too general. We need to figure out what structures are getting
so gigantic.
Overall gcc should not build too much structures at -O1 level - the rtl
reprezentation of program and the cfg. Both required to compile the program.
I am not aware of any structures built at -O1 that are not needed. How much
memory footprint changes compared to earlier versions of gcc?
The problem of CFG is the fact that it gets quadratic in the size. THis is
unavoidable with explicit reprezenation of edges in the cfg and presence of
computed jumps :(
Honza
>
> Brad