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:29: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
Reading closer, in case the edges are really the problem, I don't think
we can do something with it, except changing everything to support multiedges,
like some CFG implementations do, but that is nasty.
Concerning computed jumps, it may not be impossible to simply teach compiler
to generate single incarnation of computed jump and otherwise do jumps to
that blocks resulting in worse code, but faster compilation... It is nasty
trick, but I am not able to come with something better. You can also do it
at source level easilly in order to speed up your compiler.
Honza
> programs on my PII linux box at home because I have "only" 768 MB of
> swap space.
>
> Is there some way to not build these large internal structures if we don't
> end up using them?
>
> Brad