> > Configuration hacks that are specific to a single core create cruft and
> > maintenence problems. As I said yesterday, I think we'd be much better
> > off to have a CONFIG_CPU_MIPS_SMALL or some such option
> > that could cause -Os to be used, allow branch-likelies, etc. The optimizations
> > under discussion aren't at all specific to the 4KSd,
>
> no some are. As we said previously:
>
> 1/ sizeof(vmlinux-mips32r2-Os) > sizeof(vmlinux-4ksd-Os)
> 2/ with -march=4ksd can do (slightly) better optimizations.
This is very possibly due to the compiler knowing about the SmartMIPS
scaled, indexed load instructions, which were added to improve virtual
machine performance, but which also save on address calculation instructions.
If -march=mips32r2 combined with -msmartmips and -Os don't produce
pretty much the same result as -march=4ksd, I'd be interested in knowing
why. Regardless, if this is what's going on, there really is no other core
in production today that will run that code. But that doesn't mean
that there won't be others in the future.
All I'm really trying to do here is to get away from core-specific config
cruft. If the best result under-the-hood for 4KSd is obtained by using
-march=4ksd, that's what people should get, but I'd rather that users
and maintainers saw that as a choice of MIPS32R2+SmartMIPS rather
than a choice of 4KSd as a one-off.
Regards,
Kevin K.
