This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
> 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?
Isn't the problem caused by fact that some libcall blocks are actually bogus
at schedule time - ie one of the boundary insns is removed from the chain
already?
Honza
>
> > 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.