Re: Patch for automaton based pipeline hazard recognizer (part #1).

[Vladimir Makarov <vmakarov at redhat dot com>]

Bernd Schmidt wrote:

> 
> > + /* If the following macro value is nonzero, we will make multi-pass
> > +    scheduling for the first cycle. */
> > + #ifndef FIRST_CYCLE_MULTIPASS_SCHEDULING
> > + #define FIRST_CYCLE_MULTIPASS_SCHEDULING 0
> > + #endif
> > +
> > + #ifndef FIRST_CYCLE_MULTIPASS_SCHEDULING_LOOKAHEAD
> > + #define FIRST_CYCLE_MULTIPASS_SCHEDULING_LOOKAHEAD 0
> > + #endif
> 
> I'd like more commentary for these two.  What do they do?
> They also ought to be documented in tm.texi.
> 

  This macros control better choosing insn from ready insn queue. 
Usually scheduler chooses the first insn from the queue.  If
FIRST_CYCLE_MULTIPASS_SCHEDULING is not zero, the corresponding code
tries all permutations of FIRST_CYCLE_MULTIPASS_SCHEDULING_LOOKAHEAD
subsequent ready insns to choose insn whose issue will result maximal
number of issued insns on the same cycle.  For VLIW processor, the code
actually solves problem of packing simple insns into VLIW insn.  Of
course, if the rules of VLIW packing are described in automaton.

   On my opinion, the first insn scheduling should not do it.  It should
be done on the second insn scheduling.  So we could describe two
automata, one (simplified) for the 1st insn scheduling and another one
(with VLIW packing rules) for the 2nd insn scheduling.

   Unfortunately, VLIW packing becomes incorrect because there is jump
optimization after the 2nd insn scheduling.  We should sometime place
2nd insn scheduling after the last optimization.  This is not easy
because, jump optimization makes control flow information (used by insn
scheduling) obsolete.  We should make such movement in any case to
improve insn scheduling.

   This code also could be used for superscalar RISC processors.  Let us
consider Superscalar RISC processor with 3 pipelines. Some insns can be
executed in pipelines A or B, some insns only in pipeline B or C, and
one insn in pipeline B.  The processor may issue the 1st insn into A,
the 2nd one into B.   In this case, the 3rd insn will wait for freeing B
until the next cycle.  If the scheduler issues the 3rd insn the first,
the processor could issue all 3 insns per cycle.

  Actually this code demonstrates the advantages of automaton based
pipeline hazard recognizer, we try quickly and easy many insn schedules
to choose the best one.

Vlad