[cfe-dev] LLVM Releases: Upstream vs. Downstream / Distros

[Renato Golin via cfe-dev]

On 12 May 2016 at 16:22, Stephen Hines <srhines at google.com> wrote:
> I am 100% in agreement here. TOT regressions cost more than people think. I
> have seen firsthand how this hurts the non-LLVM parts of Android.

Hi Steve,

I think we're all in agreement of ToT development and testing. This is
more about releases and upstream users, including OS distributions.


> I am not sure why you think Android's compiler-rt is an example of a
> "heavily modified" component. As I see it, our compiler-rt matches upstream
> almost exactly (with one minor mistake from a duplicate merge that results
> in extra copies of some static functions that we don't even build). We do
> have 3 cherry-picks for some MIPS ASan patches, but all of those come
> directly from TOT master.

Sorry, that was a bit heavy-handed... I meant that it's hard to change
the Android's copy of RT because of how it's built.

This patch is an example: https://android-review.googlesource.com/#/c/125910/1

It introduces a set of nice changes that cannot go as in into LLVM's
compiler-rt because of how RT is built in LLVM.

This is not Android's fault per se, but it's an example of how
proliferation of patches can happen if one downstream repo depends on
another, as is the case for AOSP+Android+(anyone else that develops
Android).

That change should have been developed on upstream RT to begin with,
but the merge would be hard to control on the third-generation copy.

That's the reason why I want to bring all downstream repos to only
depend on upstream LLVM.


> The real problem is retaining history. Release branches don't make this very
> nice, and necessitate that we swap out an entire chunk of history for a
> different chunk of history every time we change releases.

That's interesting... I haven't heard that before, so I don't know
exactly what you mean. :)

Can you give an example?


> It is not 100% clear that Android will want to be dependent on LLVM's
> release schedule. I think that there are definitely benefits to having
> everyone do extra validation, but I am unconvinced that it is the "same"
> validation for everyone that is valuable, hence this might not make things
> go much smoother/faster for those groups.

That's a very good point, and one that I was considering while
thinking about this.

Will Sony's validation be any relevant to Chromium builds? Probably
not. But ARM's extra validation will be relevant to anyone using ARM
targets, and that in turn will bring more adoption to ARM. Sony's
validation, will be interesting to the CPUs and GPUs they validate on,
so that's a bonus to anyone who uses the same hardware.

I can't put a concrete value on any of this, but having people chiming
in is the best way to know what kind of things people do, and how
valuable they are to each other.

cheers,
--renato