Re: Gcc 3.1 performance regressions with respect to 2.95.3

[law at redhat dot com]

In message <Pine.GSO.4.33.0203181851160.27502-100000@platon>, Michael Matz writ
es:
 > Hi,
 > 
 > On Mon, 18 Mar 2002 law@redhat.com wrote:
 > 
 > >  > 	Michael Matz and I created a patch (appended) which marks each
 > >  > LIBCALL as a SCHED_GROUP.  This fixes the problem and produces much bet
 > ter
 > >  > 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
 > 
 > What's the reason? 
I don't recall.  I just know it doesn't work as you might expect, you'll
consistently hang the scheduler.

 > Conceptually the whole libcall block is one insn
 > (remember we are before reload), and ergo should be scheduled as block.
I agree, but SCHED_GROUP_P isn't the solution.  Right now we have no
solution for this problem.


 > If I understand the semantics of a libcall block, it's even wrong to
 > disrupt it by placing other insns (from outside that block without the
 > no_conflict notes) into it, which is exactly what happen when moving the
 > clobbers.  I.e.  you can schedule the block internally, you can move insns
 > outside such block, but you can't mix them.
I don't recall specific semantics, but you're probably right.


 > There's no code in schedule
 > which ensures something like this. Sure, the patch pessimizes a little bit
 > (because it even deactivates libcall internal scheduling), but what would
 > break?
The compiler will go into an infinite loop.  That's breakage in my book :-)
That was also the behavior I consistently saw when trying to use SCHED_GROUP_P
for any of my own purposes :-)

 > 
 > > What I would recommend is investigating why the clobbers were moved at
 > > all.
 > 
 > Well, simply because nothing in the whole scheduler cares for the
 > libcall blocks.
Ignore libcalls for a minute and investigate why the scheduler decided to
move the clobbers away from the use/def sites.   Something in the scheduler
decided this was a profitable thing to do, when in fact it is a very 
unprofitable
thing to do.  If you can find out why, then you have a handle on how to deal
with the performance issue.

As for the libcall semantics issue, I agree it's a problem, but it's separate
from the performance issue that started this thread.

jeff