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]

arm926 branch cost

At the end of config/arm/, branch costs are modeled with:

>;; Branch instructions are difficult to model accurately.  The ARM
>;; core can predict most branches.  If the branch is predicted
>;; correctly, and predicted early enough, the branch can be completely
>;; eliminated from the instruction stream.  Some branches can
>;; therefore appear to require zero cycles to execute.  We assume that
>;; all branches are predicted correctly, and that the latency is
>;; therefore the minimum value.
>(define_insn_reservation "9_branch_op" 0
> (and (eq_attr "tune" "arm926ejs")
>      (eq_attr "type" "branch"))
> "nothing")
In "*arm_cond_branch" and "*arm_cond_branch_reversed" have attr "type" set to "branch".

This seems to disagree with Section 8.3 of the ARM9EJ-S Technical Reference Manual (ARM DDI 0222B) which says:
"Any ARM or Thumb branch, and an ARM branch with link operation
takes three cycles"
Presumably, branches that are not taken take 1 cycle like any other non-executed conditional instruction.  

In addition, does not model the cost of alu instructions like mov, etc. with the PC as the destination.  According to the reference manual, these are either 3 or 4 cycles.

The section section above from also appears in  The arm1026 has branch prediction while the arm926 does not according to their respective reference manuals.

Am I mis-understanding what "define_insn_reservation" means?  There
does not appear to be anything the arm_adjust_cost in arm.c which
affects branching costs.



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