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