* DFA Scheduling Queries
@ 2002-10-21 9:06 Dan Towner
2002-10-21 9:37 ` Vladimir Makarov
0 siblings, 1 reply; 2+ messages in thread
From: Dan Towner @ 2002-10-21 9:06 UTC (permalink / raw)
To: gcc
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?
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?
Thanks,
Dan.
=============================================================================
Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH,
BA1 5BG
dant@picochip.com
07786 702589
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: DFA Scheduling Queries
2002-10-21 9:06 DFA Scheduling Queries Dan Towner
@ 2002-10-21 9:37 ` Vladimir Makarov
0 siblings, 0 replies; 2+ messages in thread
From: Vladimir Makarov @ 2002-10-21 9:37 UTC (permalink / raw)
To: Dan Towner; +Cc: gcc
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-10-21 14:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-21 9:06 DFA Scheduling Queries Dan Towner
2002-10-21 9:37 ` Vladimir Makarov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).