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: Brad Lucier <lucier at math dot purdue dot edu>
- To: jh at suse dot cz (Jan Hubicka)
- Cc: lucier at math dot purdue dot edu (Brad Lucier), jh at suse dot cz (Jan Hubicka), dje at watson dot ibm dot com (David Edelsohn), gcc at gcc dot gnu dot org, mark at codesourcery dot com, feeley at iro dot umontreal dot ca
- Date: Thu, 28 Mar 2002 17:22:09 -0500 (EST)
- Subject: Re: optimization/6007: cfg cleanup tremendous performance hog with -O1
>
> > [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.
Is there some way to not build these large internal structures if we don't
end up using them?
Brad