Re: [RFC] PowerPC scheduling multi-instruction patterns

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Richard Henderson writes:

Richard> This description makes no sense to me.

Richard> If the pattern will not execute in parallel, and the final instruction
Richard> in the pattern is issued two cycles after the first instruction in the
Richard> pattern, and the final instruction in the pattern has latency 1, then
Richard> it follows that the pattern as a whole has latency 3.

	First, remember the context.  The patch is attempting to inform
the scheduler about non-split, multi-instruction patterns that are a
single unit black box.

	Yes, the pattern itself has a latency of 3, but the latency of 3
includes the latencies consumed within the pattern itself.  The
scheduler's simulated cycle clock should be counting within the pattern,
but it does not because it is counting RTL insns.

	The scheduler needs to determine when to emit the next dependent
instruction.  A latency of 3 means that the scheduler should try to emit
two other unrelated instructions to hide the latency of the pattern, but
the pattern itself includes the two instructions it should be counting.

	If instead one asks the question: When should the scheduler emit
the next dependent instruction?  The answer is the next cycle -- the
latency of the last instruction.

	The reason for the patch is that the old description did not
correctly inform the scheduler about function unit usage and dispatch
group formation with the primary problem being dispatch group formation.
One could argue that the instruction should be represented as occupying
all of the function unit resources in the first cycle after dispatch or
only should represent the function unit resources of the last instruction.
The best way to describe the function unit occupancy is an open question
and I am eager to hear advice, but I believe that the latency is correct.

David