Steve Ellcey <sell...@imgtec.com> 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, 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.
>
> Hm, I think the problem may be that mips32r2 defaults to PROCESSOR_M4K
> and mips32 defaults to PROCESSOR_4KC. I don't see any special scheduler
> for m4k. Is there supposed to be a scheduler for m4k?
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 representative of the general case. TUNE_74*
has quite a lot of special code associated with it, whereas TUNE_24*
sets TUNE_MACC_CHAINS, which might overemphasise the use of MADD
for 74k targets when -mimadd is used.
But any choice is going to be a compromise. A patch to do either
is preapproved.
Thanks,
Richard
