[PATCH] Modulo-scheduling improvements. Patch 2 of 2.

[Ayal Zaks]

andrey.belevantsev@gmail.com wrote on 26/06/2007 21:40:14:

> On 6/26/07, Ayal Zaks <ZAKS@il.ibm.com> wrote:
> > Note that we
> >               /* Mark this loop as software pipelined so the later
> >               scheduling passes doesn't touch it.  */
> >               if (! flag_resched_modulo_sched)
> >                 g->bb->flags |= BB_DISABLE_SCHEDULE;
> > as the second scheduler may mess things up in its ignorance of
> > cross-iteration dependencies.
> Sorry, I forgot about this in my previous reply.  Messing the SMS
> schedule is definitely an issue; however, if a target splits a lot
> after the first scheduling, you may get suboptimal schedule in SMS, as
> you'd not get an exact processor model.  (I remember Vlad expressing
> similar concerns.)  So, maybe it makes sense to allow the second
> scheduling,

Sure, that flag is there to see what works best.

> but also to limit the scheduling freedom somehow (with
> extra dependencies?) so that the general outline of the SMS schedule
> will be retained.
>

Hmm. One could compute earliest ready times for insns that depend on insns
from the previous iteration, based on the current position of these latter
insns. Scheduler is currently unaware of these cross iteration deps.

 > As of the doloop pattern discussion, I would like this patch to go in
> as is, so that SMS on ia64 will work.  Extending SMS to handle doloops
> via cfgloop.c could be done later in stage 2, and if you would not
> have time for this, then at least ia64 users will get working SMS in
> 4.3.  I could test the subsequent patches on ia64 too.  This is
> helpful as ia64 has a different kind of the doloop pattern than spu.
>

Yes, I'd like to push these patches and make incremental progress.

> I will also test whether rescheduling SMS loops makes any sense on ia64.

Thanks.
Ayal.

>
> Andrey