40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

Daniel Berlin dberlin@dberlin.org
Mon Feb 19 23:40:00 GMT 2007

On 2/19/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Daniel Berlin wrote:
> >> > > > It looks like your changeset listed bellow makes performance
> >> > > > regression ~40% on SPEC2006/leslie3d. I will try to create minimal
> >> > > > test for this issue this week and update you in any case.
> >> > The price of fixing them in 4.2 was a serious performance drop.
> >>
> >> There's the option of un-fixing them to get back to the state of 4.1
> >> declaring
> >> them fixed in 4.3 earliest.
> I would like to understand a few things:
> 1. What is the overall drop in SPEC scores as a result of this patch?  I
> understand the impact on leslie3d, but what is the overall impact?
> Hopefully, this is an easy question to answer: run SPEC, revert the
> patch, run SPEC again.

I'll let others answer this (i don't have spec2006), but there have
been reports filed about other spec2006 benchmarks as well on the 4.2
branch already.

> 2. What is the effort required to backport the necessary infrastructure
> from 4.3?  I'm not looking for "a lot" or "is hard", but rather, "two
> weeks" or "six months".  What needs to be backported, and what are the
> challenges?

Including bug fixes, i'd guess 2 months to be conservative.  It may be
faster, of course.
The main problem is that the patches are now intermingled with other
changes that happened at the same time.  Other than that, they should
be pretty directly applicable.
There are quite a few of them though (5 or 6 large patches).
The other challenge is that some of the patches were written after
mem-ssa merged, and that changed a lot of little infrastructure
These patches will not directly apply to 4.2 anymore, and it's going
to just take time to convert them. How much? A week per patch or less,
i'd guess.
There are no real challenges other than applying the patches and doing
a lot of testing, since most of these patches were written pretty
early on during the 4.3 cycle.

> 3. Is there any conceivable way to fix the alias analysis for 4.2 so
> that it is robust, but not overly conservative, even if that means a
> special algorithm just for 4.2?  Yes, that would be a bizarre thing to
> do on a release branch, but humor me: is it possible, and what would it
> take?
We had one in 4.2 prior to these fixes, but it used a huge amount of
memory on large testcases.
So it's possible, of course.

More information about the Gcc mailing list