[PATCH] insn priority adjustments in scheduler and rs6000 port

Vladimir Makarov vmakarov@redhat.com
Tue Sep 30 22:17:00 GMT 2003


Ayal Zaks wrote:
> 
> >  As for the patch about scheduling of queued insns, it is more
> >controversial.  The same comments are applicable to the patch.  But I
> >need to think more about the patch idea because it violates the
> >scheduler design:
> >
> >1. insns are issued only from ready.
> 
> True, insns are now issued only from ready; but that might cause the
> scheduler to suffer from near-sightedness, which this patch is trying
> to change (see e.g. http://gcc.gnu.org/ml/gcc/2003-03/msg01688.html
> Problem 2).
> 
> >2. queue contains insns which can not be issued on the
> >   current cycle (because of the data or resource delay).
> 
> Queue contains insns which are waiting to be ready, but it is only
> a matter of time before they become ready. Indeed, if the ready-list
> is empty, the next insn that will be scheduled usually comes from the
> queue after bumping enough cycles. This patch is trying to provide
> some "lookahead" into future promising scheduling candidates, and
> allows to mitigate their time in the queue if they are "urgently"
> needed. The queue does not contain insns that still depend on other
> insns to be scheduled before them. At any rate, the patch explicitely
> checks if an insn can be scheduled before grabbing it from the queue.
> 
> The patch tries to improve support for targets that have issue-queues,
> where delays can occur between the time an insn is fetched/dispatched
> (which is important for insn packing considerations) and the time it
> is executed (relevant for data-dependent latency considerations). The
> alternative of noop padding is not always desirable.
> For such targets, queue contains insns which cannot be executed on the
> current cycle (because of the data or resource delay), but they can
> be issued on the current cycle (and they should, to reduce noops).
> 

  Yes, I understood the idea of the patch the first time.  I just worry
about that the patch considerably complicates the scheduler.  I think
last Dorit's idea to implement the same approach is much better because
it is simpler.  The scheduler is already complicated (many hooks which
is probably because of big dependence of the optimization on target
architectures) and radical changes in core algorithm (and design) is not
reasonable approach in my opinion.

Vlad



More information about the Gcc-patches mailing list