Re: DFA quantitative slot restriction

[Vladimir Makarov <vmakarov at redhat dot com>]

Dan Towner wrote:
> 
> Hi all,
> 
> I am using the DFA scheduler to target a VLIW processor. The processor
> has 3 slots, plus a special immediate constant slot. The constant slot
> may be used by any *one* of the other three slots.
> 
> I want to be able to restrict the VLIW packet to use no more than 3 of
> the 4 slot resources (e.g., 3 instructions, without a constant, or 2
> instructions, one of which uses a constant). Setting ISSUE_RATE to 3
> won't work though, because there one instruction might use two slots. I

  The simplest thing is to modify the DFA description.  Just describe
processor with 3 slots one of which is used for the constant.  If you
need to switch on/off such insn scheduler behaivour, you could add the
new description (with 3 slots one of which is used for the constant)
with a condition controlled by a compiler option flag.

> thought about using the TARGET_SCHED_VARIABLE_ISSUE hook, but this won't
> work either, for the same reason. For example, if 2 instructions have
> been issued already, then another 1 instruction can be issued, so long
> as it doesn't contain a constant. However, the VARIABLE_ISSUE hook might
> work if it knew what instruction was about to be scheduled. Is it safe
> to store a reference to the ready list, so that the next instruction can
> be examined (e.g., in SCHED_REORDER)? I am using the
> MULTIPASS_DFA_LOOKAHEAD as well - would storing a reference to the ready
> list in SCHED_REORDER invalidate some of the assumptions of DFA_LOOKAHEAD?

  SCHED_REORDER is called only on the new simulated processor clock
start.  The multipass scheduling works only during one cycle.  So they
does not need to take each other into account.  There is a hook
SCHED_REORDER2 which is called after each insn issue.  In some way the
multipass scheduling ignores the reordering.  On the other hand the
multipass scheduling guarantees that the first insn in the ready queue
will be issued on the current cycle.  So if reorder2 changes the first
insn in the ready queue, the multipass scheduling will be confused.  So
the advice is not to reorder insns in SCHED_REORDER2 if you use the
mutipass insn scheduling.

Vlad