[llvm-dev] The state of ARMConstantIslandPass in 4.0.[01]

[Renato Golin via llvm-dev]

On 30 May 2017 at 10:06, Ariel Ben-Yehuda <ariel.byd at gmail.com> wrote:
>> They may behave well in trunk because of other patches that were
> noticed and fixed, but back-porting just those patches may introduce
> instabilities that weren't fixed in 4.0.
>
> That's what's worrying me. Because we don't want to ship a version of
> Rust on which developing on ARM is a minefield, we have to apply the
> first 2 patches. However, it looks that we might also need to apply
> the other patches, and I'm worried about whether and how can they be
> safely backported.

This is unfortunate, but it happens from time to time.

If the problem was found in 4.0.0, we'd probably merge all the fixes,
because the tree was still fresh. But now months have passed, and we
need to be extra careful.


> Could the patch authors pitch in?

Of course they can. But the decision to merge or not will always falls
back on the stable release manager, with inputs from the code owners
and the authors.

The primary concern of the stable releases is not to have a stable
product as in "works robustly and is free of egregious bugs in all
primary architectures", but as in "has the same behaviour as the
previous stable release with bug fixes".

If the bug fixes introduce instability, they are not back ported. We
want bugs fixed with minimised risk of introducing other unknown bugs
on other parts of the compiler.

In essence, better to have a known bugs than unknown ones.


> In our experience, every new version of LLVM both requires some
> porting work and introduces new issues in non-P1 targets that need to
> be fixed. We'll upgrade to LLVM 5.0 as soon as it gets released and we
> port and apply the fixes. In the meanwhile we'll like a version in
> which ARM is less of a minefield.

Every new version of LLVM has issues on all targets. Like x86, the ARM
targets are primary, but they may have a bit less "user validation".

The constant island pass is special because it was improved not long
ago, and the original implementation was very... simple. The
improvement was done with some testing, but as usual, testing on ARM
is a never ending story.

A toolchain that is trying to target all ARM targets, from ARMv4 to
ARMv8, from bare metal to enterprise, on Linux, Mac and Windows,
*will* have gaps in the testing. x86, OTOH, has a lot less dimensions
and a lot more people building on it daily for very different
purposes.

Unfortunately, the policy around major releases and stable releases is
one that has been beaten repeatedly and every time the consensus is
the same: Every interested party validates their own trunk, for their
own purposes, and the upstream releases are just "a point in time that
had some more attention" not a "guarantee of stability and quality".

With that in mind, it's not unlikely that big problems will arise and
we'll encourage you to wait for the next release. Worse case scenario,
you can pick 3.9 instead, or take current trunk and validate locally.

cheers,
--renato