Gcc 3.1 performance regressions with respect to 2.95.3

[law@redhat.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