On Wed, 2013-05-22 at 07:30 +0100, Richard Sandiford wrote:
> Oops -- only if someone submitted one :-) So we should definitely
> change the mips32r2 entry. I'd suggest one of PROCESSOR_24KF* or
> PROCESSOR_74KF*, so that we get the FPU scheduling, but I don't know
> which would be more represen
Steve Ellcey writes:
>> 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
On Tue, 2013-05-21 at 19:55 +0100, Richard Sandiford wrote:
> 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 t
"Steve Ellcey " 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
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
intege
