Hi everyone,
I have come across a problem with my port of gcc regarding the way that
shorten_branches interacts with delay slot scheduling.
My port's target processor has two types of conditional branches: long
and short branches. Short branches have a delay slot, and long branches
don't. The two types of branches have different lengths. The length
attribute of the insn is set using the following expression:
(set (attr "length")
(if_then_else
(and (ge (minus (match_dup 0) (pc)) (const_int MIN_BRANCH_OFFSET))
(le (minus (match_dup 0) (pc)) (const_int MAX_BRANCH_OFFSET)))
(const_int SHORT_BRANCH_LENGTH)
(const_int LONG_BRANCH_LENGTH)))
I want to be able to use the delay slot of the short branches, so I set
the type attribute of the insn from the length attribute (is this wrong?):
(set (attr "type")
(if_then_else
(eq_attr "length" "6")
(const_string "branchWithDelay")
(const_string "branchWithoutDelay"))
During the insn output, I then look at the length field to decide
whether this is a long or short branch, and whether I should look for a
dbr_sequence to write out in the delay slot.
The problem I am seeing is that some branch instructions are marked as
short branches, with delay slots. The delay slot scheduler runs, and
moves some instructions into the delay slots. The shorten_branches code
is then run, and discovers that the addresses of the branches have
changed slightly, and what were short branches become long branches. At
the instruction output stage, the long branches are then emitted without
the necessary directives to configure their delay slots.
Am I doing something fundamentally wrong with the way I am defining the
length attribute, or the delay slot attribute? Is there any way that I
can prevent an instruction which has previously been marked as a short
branch to stop it being converted back into a long branch? The branch
distances only change by a few bytes, and the branch distance
computation already has a bit of slack to allow the assembler to add
some extra alignment, so a branch marked as a short branch will never
get long enough to genuinely need a long branch instruction.
Thanks,
dan.
--
============================================================================
Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
[EMAIL PROTECTED]
+44 (0) 7786 702589
