"Steve Ellcey " <sell...@imgtec.com> writes:
> While looking at some matrix code I noticed that the generic mips scheduler
> was putting out a bunch of integer madd instructions in a row and that
> I got better performance (on 74kc and proAptiv) when they were spread out.
>
> I was wondering what folks thought of this change to specify that the
> integer madd instruction uses the alu and the imuldiv functional units?
>
> Tested on 74kc and proAptive with no regressions and better performance.
Hmm, but generic.md is very much legacy and shouldn't be used for
vaguely modern cores. Even something like -mips32 is supposed to avoid
the generic scheduler; it should use the 4k scheduler instead.
What options were you using to trigger it?
generic.md is actually inherited by some of the very old, pre-DFA schedulers,
including those that were probably used with the old PMC cores. I'm not
even sure how much generic.md was ever supposed to be a good "all-round"
scheduling description, akin to the modern -mtune=generic on x86 targets.
I'm a bit reluctant to change it at this stage.
It might be worth having a new "generic" scheduler that's supposed to be
a good compromise for modern cores though. Or, more simply, we could just
change:
MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("mips32r2", PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
/* ??? For now just tune the generic MIPS64r2 for 5KC as well. */
MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
to tune for other processors instead, if you don't think 4kc, etc. are
representative enough.
Richard
