On 18/10/12 18:48, Ramana Radhakrishnan wrote: > +(define_insn_reservation "cortex_a15_vfp_adds_subs" 6 > + (and (eq_attr "tune" "cortexa15") > + (eq_attr "type" "fadds")) > + "ca15_issue1,ca15_cx_vfp")
Ramana, I noticed you use here the fadds value for the type attribute to activate this rule. This same test is also used in this generic_vfp rule: ... (define_insn_reservation "vfp_farith" 8 (and (eq_attr "generic_vfp" "yes") (eq_attr "type" "fadds,faddd,fconsts,fconstd,f_cvt,fmuls,fmacs,ffmas")) "fmac") ... and the generic_vfp is yes for cortex-a15, so these 2 rules are active at the same time. The documentation states: ... You should remember that you will be in trouble if condition for two or more different define_insn_reservation constructions is TRUE for an insn. In this case what reservation will be used for the insn is not defined. ... I made an example, looked at the sched2 dump and found that the cortex-a15 rule was active. Moving vfp11.md to before cortex-a15.md made the other rule active. Are we exploiting some undocumented (partially) defined behavior here with respect to order, or is this a latent bug? Thanks, - Tom