killed schedule groups?

Vladimir Makarov vmakarov@redhat.com
Thu Jan 16 22:26:00 GMT 2003


Jan Hubicka wrote:
> 
> > Richard Henderson wrote:
> > >
> > > On Wed, Jan 15, 2003 at 05:38:37PM -0500, Vladimir Makarov wrote:
> > > > > Why did you kill the effect of SCHED_GROUP_P?  This was not
> > > > > an idle suggestion -- this is needed for correctness on a
> > > > > number of targets.
> > > >
> > > > I've killed because of more accurate insn scheduling (accurate changing
> > > > reservation state) and scheduling insns in the group.  The group is
> > > > represented now by additional dependencies.
> > >
> > > I can't see how this is a good plan.  In general we can't allow *any*
> > > instructions to interleave with the sched group.  Which would mean
> > > that you'd have to have all insns that initially appear before the
> > > group anti-dependent on the first insn of the group, and all insns
> > > that initially appear after the group dependent on the last insn of
> > > the group.  Which means that we're now completely unable to move any
> > > insn across most calls, when all we really care about is that if we
> > > move an insn it either goes before or after the group, and not in
> > > the middle.
> > >
> > > Given that sched groups only occurr before reload, I have no problems
> > > accepting less accurate reservation state.
> > >
> >
> >   It has a sensible effect even on the 1st insn scheduling quality (at
> > least for itanium).  The schedule group could be a few insns.  They can
> > not be issued on one cycle in many cases.  The scheduler look at them as
> 
> Perhaps the problem is just that the SCHED_GROUP_P should be ignored
> only after reload when the regalloc issues are void...
> 

Sched groups were not formed after reload (except CC0
producer-consumer).

Vlad



More information about the Gcc-patches mailing list