On 12/20/2010 9:01 AM, Ulrich Weigand wrote:

Well, I understand we -as Linaro- would like to see Ubuntu base their compiler on ours, but Ubuntu prefers to use a single source base for the compiler for all their supported platforms, including SPU. If we break some of those other platforms in the Linaro compiler, that just creates extra problems for Ubuntu ...

I certainly understand that desire; I'm just asking how sustainable it is and where the commitments ought to lie. I'd just guess that this would be an ongoing problem, and that there will be a tension between "make the best possible ARM Linux system" and "don't break other architectures".

Thank you,

On 12/20/2010 10:54 AM, Matthias Klose wrote:

So, I'll build without Linaro on powerpc. Next we'll see regressions on ix86 and x86_64, which are not fixed, so stop building these architectures without the Linaro changes? Or build without Linaro on ix86 and x86_64? Or maybe be a bit more conservative what gets into the Linaro toolchain?

I'm not trying to take an extreme position; I'm really looking for an answer here. We've got something approaching 100 engineers doing ARM-oriented work in various components. They build on ARM, test on ARM, benchmark on ARM. They live ARM, they breathe ARM. I think it's likely they're going to break non-ARM, no matter how well-intentioned they are.

So, the question is what policies we should have pre-checkin (to validate other architectures) and post-checkin (when a problem is reported on another architecture). I don't think we have very good clarity there. I suspect that if more distributions start taking more technology from Linaro, we'll see this issue arise more and more often.

Correctness is a relatively easy case, but what happens when we see that a 10% performance improvement on ARM resulted in a 2% decrease on MIPS or 3% on x86? What commitment, if any, are we making to a distribution that cares about all of ARM, MIPS, and x86?

Thank you,

On Mon, Dec 20, 2010, Mark Mitchell wrote:

I certainly understand that desire; I'm just asking how sustainable it is and where the commitments ought to lie. I'd just guess that this would be an ongoing problem, and that there will be a tension between "make the best possible ARM Linux system" and "don't break other architectures".

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.

This thread is going into Linaro toolchain policies at the worst time of the year while key stakeholders are away (/me waves to Michael Hope) but I believe the position on the goals of the Linaro Toolchain were made extremely clear: neutral on correctness (no regression introduced by Linaro changes) and focus on improving performance on modern ARM CPUs (ARMv7+).

Now you bring up more subtle problems, pointing out that there is a grey area when e.g. performance improves vastly on ARM and degrades on other arches. I am pretty sure upstream has a good approach to solve this use case, I would expect that the feature is either disabled by default on non-ARM or only enabled on ARM, or that it's protected by a flag and that people with a clue about the flag only use it on ARM or never use it on non-ARM. I'm sure there are better approaches than manual "ifdefs" or "ifs" to deal with these issues as well, for instance the compiler actually checking whether it will generate slower code or not, and selecting the best course of action for you. But my point is not how to solve each particular problem, it's rather that we should solve the problem exactly how it would be solved to get it upstream.

Another question is the one of testing; we're testing on ARM and on x86. Testing can always be improved, and it will improve over time. I don't think we can be expected to test all possible architectures, just like the other contributors to GCC don't test all architectures when submitting code changes. Concerning PPC, we wouldn't want to regress it any more than other architectures, and if PPC-specific issues are triggered by Linaro patches, heck we should fix them! But I don't expect we'll validate each and every patch on PPC, MIPS, SH...

I think what happened here is exactly what we wanted to happen: some PPC specific regressions were discovered once the patches got wider adoption, Ulrich did the right thing in raising the conflict between PPC expectations and the Linaro changes and we need to discuss a good path forward so that these patches can be included upstream. Exactly as this would be discovered/discussed upstream :-)

We can meet in Dallas in ~20 days and discuss this face to face as well :)

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