This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

interaction between shorten_branches and delay slot scheduling

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")
       (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")
    (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.



Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
+44 (0) 7786 702589

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]