Re: DFA Scheduling Queries

[Vladimir Makarov <vmakarov at redhat dot com>]

Dan Towner wrote:
> 
> Hi all,
> 
> I am working on a port of gcc targeting a 16-bit VLIW DSP. I am using
> DFA instruction scheduling, and I have a couple of queries with regard
> to the best way of using this.
> 
> The instructions can be divided into the basic classes: simpleAlu,
> complexAlu, loadStore, branch, and multiply. Each VLIW packet has 4
> sub-packets, which can hold:
> 
>     1) simpleAlu
>     2) simpleAlu or complexAlu
>     3) multiply or loadStore or branch
>     4) immediate constant
> 
> I have created a cpu unit for each of these sub-packets:
> 
>    (define_query_cpu_unit "slot0,slot1,slot2,slotC")
> 
> I have created reservations for each instruction type, so that it uses
> the correct slots. For example, a simple instruction can go in either
> slot 0 or slot 1:
> 
>    (define_insn_reservation "simpleAluInsn" 1
>      (and (eq_attr "type" "simpleAlu"))
>       "(slot0|slot1)")
> 
> Similarly for all the other instructions - they are mapped to the
> appropriate slots.
> 
> My first question is how to represent the immediate constant slot.
> Currently, I have defined two forms for each instruction, one with the
> constant, and one without. For example, the above reservation could
> actually be:
> 
>   (define_insn_reservation "simpleAluInsn" 1
>    (and (eq_attr "type" "simpleAlu") (eq_attr "hasConstant" "false"))
>    "(slot0|slot1)")
>   (define_insn_reservation "simpleAluInsnWithConst" 1
>    (and (eq_attr "type" "simpleAlu") (eq_attr "hasConstant" "true"))
>    "(slot0|slot1)+slotC")
> 
> Thus, every one of my reservations comes in one of two forms: with and
> without a constant. Is this the best way of representing this
> requirement, or can I do better?
> 

That is a good way to describe it.

> My second question relates to scheduling instruction sequences which use
> status registers. For example, a 32-bit add can be handled as a 16-bit
> add (which generates a carry), followed by a 16-bit add-with-borrow
> (which pulls in and uses the previously generated carry flag). Once the
> first instruction has executed, the second instruction can execute in
> either slot0, or slot1, at any point, *provided no other instructions
> modifies the carry flag* (actually, to be precise, such modifying
> instructions can be executed in slot1, which can't modify the status
> flags). How can I describe such a situation using the DFA scheduler - is
> it even possible?

  Such description is also an issue to the old insn scheduling.  It
should be described not by unit reservations.  It should be described by
data dependencies. The insn patterns should explictly refer for the flag
or you should use CC macros (please see Condition code status in gcc
internal documentation).  After proper description, the insn scheduler
will never insert an insn modifying the carry flag between the two insns
`add' and `add-with-borrow'.

Vlad