On Wednesday 01 September 2010, Michael Hope wrote:
We will try to do no harm to other architectures or earlier ARM versions. The Thumb-2 routines may be applicable to the Cortex-M and Cortex-R series but we will not optimise for them.
I'd like Linaro to state this explicitly in the next round. https://wiki.linaro.org/Linaro1011/TechnicalRequirements defines a 'Standard ARMv7 Configuration' but there's no higher level statement justifying it, no statement restricting us to it, and it includes ARM, Thumb-2, and Thumb-1.
I think there are two aspects to this:
On the one hand, we need to improve the code formost for new CPUs looking forward, so the latest generation of shiny high-end hardware is what matters the most and needs to be the primary target. Today's high end is tomorrow's mainstream, so sooner or later everyone will benefit from this.
On the other hand, I think we need to be relevant and provide code that everyone can use. The market today mainly consists of stuff that's not the primary focus, like ARM926 or some non-MMU cores. Refusing to do a simple fix because it's not relevant for Cortex-A8/A9 will just manage to piss off people [1].
Obviously there has to be a middle ground. We're building the binary packages for the configuration Dave mentioned (v7A/Neon), but IMHO that shouldn't prevent anyone from rebuilding it with our tool chain without having to make significant changes. If there are patches readily available for stuff that's not our primary focus (thumb1, non-cortex v7A CPUs, vfp without neon, ...), I'd say we should still keep them or get them upstream.
Arnd