This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
- From: law at redhat dot com
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>, Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 18 Mar 2002 10:15:35 -0700
- Subject: Re: Gcc 3.1 performance regressions with respect to 2.95.3
- Reply-to: law at redhat dot com
In message <200203180034.TAA28298@makai.watson.ibm.com>, David Edelsohn writes:
> Michael Matz, Daniel Berlin, and I tracked down a performance
> regression that Franz Sirl had reported with -O2 causing excessive stack
> usage. I do not know if this problem affects the benchmarks being
> discussed, but I thought that I might as well mention if for this topic.
>
> The problem we found is that the first scheduling pass is moving
> the instructions in LIBCALLs far apart -- moving the CLOBBERs very early.
> This creates artificially large lifetimes for the pseudos. The local and
> global register allocators could not allocate the pseudos to registers, so
> reload ends up creating massively large stacks to home each pseudo over
> its long lifetime.
>
> Michael Matz and I created a patch (appended) which marks each
> LIBCALL as a SCHED_GROUP. This fixes the problem and produces much better
> code. Andreas Jaeger ran this through his SPEC tester showing
> improvements on some tests and no regressions.
That won't work. You can't just tack on SCHED_GROUP_P like that (I know, I
tried to do it a few years ago to fix a similar, but different problem).
What I would recommend is investigating why the clobbers were moved at all.
jeff