Re: GCC DFA Scheduling Query

[Vladimir Makarov <vmakarov at redhat dot com>]

Pankaj Dev wrote:
> 
> Hi,
> 
> Actually I am working on the modification of DFA Description for the
> sparclet processor in GCC 3.3.1 which I downloaded on Aug 11,2003.
> 
> I am actually curious about the DFA description of sparclet already in GCC.
> Being a single-issue instruction machine, the execution description says
> that each instruction is first "Fetched and Decoded" in the FETCH AND DECODE
> UNIT and then is executed by the corresponding unit i.e. ALU, MAC, LOADSTORE
> and then the results are written back by the WRITE BACK UNIT.
> 
> Since there is only one unit available for each FETCH AND DECODE and WRITE
> BACK unit so I feel that they should also be included in the
> insn_reservation description in the .md file.
> 
> For e.g.
> (define_insn_reservation "sl_imul" 7
>   (and (eq_attr "cpu" "sparclet")
>     (eq_attr "type" "imul,idiv"))
>   "sl_fetch_decode, sl_imul*5, sl_writeback")
> 
> Because I feel that this would help to create a better DFA and generate the
> instruction schedule better. I just wanted to know if I am wrong in my
> understanding.
>

Sorry for the delay with the answer.  I was sick.  Jim Wilson answered
you many questions correctly.  I think the sparclet description is just
translation of the old pipeline description.  The old description model
can not permit to describe a unit reservation not from the insn
execution start.  So nobody tried to describe "writeback"
 
> Also it seems that latency description "7" and the instruction resource
> reservation "sl_fetch_decode, sl_imul*5, sl_writeback" are not consistence
> with each other.
>
Yes, it looks like.  I have no manuals for sparclet  processor.  So I
can not say what is wrong.
 
> For e.g. the above description could also be written as
> 
> (define_insn_reservation "sl_imul" 5
>   (and (eq_attr "cpu" "sparclet")
>     (eq_attr "type" "imul,idiv"))
>   "sl_fetch_decode, sl_imul*5, sl_writeback")
> 
> So Actually why aren?t they related or probably if there is some other
> understanding behind this concept. In the sense that for the DFA
> construction which of them is used for what purpose.
>

Latency time is used in most places of insn scheduler (longest path
calculation, insn priorities, data-ready delays and so on).  It is the
most important parameter of the description for the insn scheduler.  The
reservation is used for finding a resource delay.  In general, the
reservation length can be unequal to the latency time because there may
be some undescribed activity (at the start or end of insn execution). 
E.g. we could describe sl_fetch_decode as sl_fetch+sl_decode or as
sl_fetch or as just sl_decode and have the same DFA.
 
> As written in the manual Adjusting the Instruction Scheduler
> ///**************************************
> int TARGET_SCHED_ISSUE_RATE (void)      Target Hook
> This hook returns the maximum number of instructions that can ever issue at
> the same time on the target machine. The default is one. Although the insn
> scheduler can define itself the possibility of issue an insn on the same
> cycle, the value can serve as an additional constraint to issue insns on the
> same simulated processor cycle (see hooks TARGET_SCHED_REORDER and
> TARGET_SCHED_REORDER2). This value must be constant over the entire
> compilation. If you need it to vary depending on what the instructions are,
> you must use TARGET_SCHED_VARIABLE_ISSUE. "For the automaton based pipeline
> interface, you could define this hook to return the value of the macro
> MAX_DFA_ISSUE_RATE. "
> 
> ///**************************************
> But the macro MAX_DFA_ISSUE_RATE has the value 4 in insn-attrtab.c and
> sparclet is a single-issue instruction machine. So if we return this macro
> from Target Hook TARGET_SCHED_ISSUE_RATE, I feel it will be returning wrong
> information from the Target Hook since issue_rate here should be 1 only,
> which is currently the default value, returned from it.

MAX_DFA_ISSUE_RATE is calculated from the insn reservations.  4 means
that the reservations for sparclet insns are described inaccurately. 
But this inaccuracy is fixed by ISSUE_RATE hook and the scheduler still
believes that only one insn can be issued per cycle.

Sparclet could be described more accurately.  But it seems that nobody
worries about gcc for this processor.  I even don't know where to find
sparclet documentation and a board with processor to figure out what
kind of improvement we could have with the new description.

Vlad