Re: [PATCH] insn priority adjustments in scheduler and rs6000 port

["Ayal Zaks" <ZAKS at il dot ibm dot com>]

>  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).

Ayal.