On Wed, Dec 22, 2010 at 7:50 AM, Mark Mitchell <m...@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
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
