Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)

[Loïc Minier]

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
 :)

-- 
Loïc Minier