On 06/26/13 09:37, Tom de Vries wrote:
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?
Nice catch - No this is just a latent bug and is just an oversight.
We should just remove the A15 from the generic vfp scheduler.
regards
Ramana
Thanks,
- Tom
