Gcc 3.1 performance regressions with respect to 2.95.3

[Michael Matz]

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 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

What's the reason?  Conceptually the whole libcall block is one insn
(remember we are before reload), and ergo should be scheduled as block.
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.  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?

> 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.


Ciao,
Michael.