On Wed, Dec 22, 2010 at 7:50 AM, Mark Mitchell mark@codesourcery.com wrote:
On 12/21/2010 2:12 AM, Loïc Minier wrote:
Upstream faces the same problem, yet manages to move the compiler forward. Since Linaro's goal is for all new developments to make it upstream, we should simply live by upstream's standards when developing patches.
However, Linaro doesn't have upstream's resources. In the context of upstream, if you post a patch that works on (say) ARM, but breaks on (say) SPU, then it's your obligation to fix that problem. But, you generally have the combined resources of upstream, including a lot of expertise from maintainers of other architectures to draw on. In Linaro (despite the fact that we have Ulrich Weigand, a very talented Power developer, and Richard Sandiford, an equally talented MIPS developer), we do not have the breadth of knowledge that we have upstream.
So, I'm questioning the objectives. Linaro isn't upstream. It's not a multi-architecture consortium. It's all about ARM. Therefore, a multi-architecture distribution that wants to provide best-in-class tools for all architectures cannot rely completely on Linaro; there will be important patches for MIPS, Power, x86 and other architectures that are not going to be incorporated into the Linaro sourcebase.
I'd rather the criteria for Linaro be that the Linaro sourcebase work well on ARM. Of course, we should submit patches upstream as well. In that process, the patches will change, to better support other architectures, or otherwise. We can backport those changes, or we can just wait for our next merge from upstream, and get them then.
This would give Linaro the clearly focused mission of providing excellent tools for ARMv7-A.
I'm more than a month late to the party, but here goes:
I've said the following in the flyer[1]:
""" The group's goal is to improve the competitiveness of Cortex-A series devices, especially the Cortex-A9 with NEON and SMP. We emphasise performance and are neutral on correctness. Most of the performance effort is on improving compilers and libraries, and some is on providing good developer tools to allow the developer to track down the remaining issues and get the device to market.
The primary platforms are Linux on Cortex-A, i686, and x86_64. Improvements are done for the Cortex-A. The other primary platforms are built, tested, and supported by the group. This gives us a wider range of tests, makes changes more likely to be accepted upstream, and makes the toolchain more useful for multi-platform products such as Ubuntu.
While we do focus on the Cortex-A, we attempt to 'do no harm' to other architectures. The performance and correctness should be no worse than the corresponding upstream version. We plan to monitor the correctness, speed, and size of the automated builds in the following combinations:
ARMv7 + Thumb2 + VFP ARMv5 + ARM + Software FP ARMv5 + Thumb1 + Softare FP i686 x86_64
Correctness regressions will be fixed. Significant size or performance regressions will be fixed. """
So: 1. If we break (any) ARM, i686, or x86_64, we'll fix it 2. Similarly, if others find our ARMv7, i686, or x86_64 to be broken, we'll fix it 3. If we break any other architecture we won't know unless others get involved 4. Performance *could* drop on i686 and x86_64. We'll measure it and see if it's a problem.
(1) and (2) should be sufficient for a distro like Ubuntu to use Linaro GCC for all of their official platforms. (1) and (2) are also an honest effort and, if we can meet these, then the patch should be acceptable upstream and gives us the advantage of exercising more of the middle end.
The counter examples are more interesting: * If others find Thumb-1 to be broken, it should be fixed by the greater ARM community upstream * If a change in Linaro GCC 4.5 breaks PowerPC, we might not fix it * If a change from us in trunk drops MIPS performance by 2 %, we might not fix it
When push comes to shove, performance on ARMv7 wins. Things should smooth out once trunk opens again as we'll be working upstream and can use upstream's normal methods and resources to solve such problems.
I'm working on doing builds in the cloud and once we have that I'll start doing a cross builds for architectures with readily available sysroots (Ubuntu has at least sparc and powerpc). Automation makes this cheap and, although we still don't support them, it'll give early warning for some types of fault.
[1] https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer
-- Michael