llvm dev - Feb 2014 - [LLVMdev] Zero-cost toolchain "standardization" process

Hi Folks,

First of all, I'd like to thank everyone for their great responses and
heart warming encouragement for such an enterprise. This will be my
last email about this subject on these lists, so I'd like to just let
everyone know what (and where) I'll be heading next with this topic.
Feel free to reply to me personally, I don't want to span an ugly
two-list thread.

As many of you noted, not everyone is actively interested in this, and
for good reasons. The last thing we want is yet-another standard
getting in the way of actually implementing features and innovating,
which both LLVM and GCC are good at. Following the comments on the GCC
list, slashdot and Phoronix forums, I think the only sensible thing is
to do what everyone said we should: talk.

Also, just this week, we got GCC developers having patches accepted in
LLVM (sanitizers) and LLVM developers discussing LTO strategies on the
GCC list. Both interactions have already shown need for improvements
on both sides. This is a *really* good start!

The proposal, then, is to have a zero-cost process, where only the
interested parties need to take action. A reactive system where
standards are agreed *after* implementation.

1. A new feature request / implementation on one of the toolchains
outlines what's being done on a shared place. Basically, copy and past
from the active thread's summary into a shared area.

2. Interested parties (pre-registered) get a reminder that new content
is available. From here, two things can happen:

  2.1 The other toolchain has the feature, in which case developers should:
    2.1.1 Agree that this is, indeed, the way they have implemented,
and check the box: "standard agreed".
    2.1.2 Disagree on the implementation and describe what they've done
instead.

  2.2 The other toolchain doesn't have it:
    2.2.1 Agree with the implementation and mark as "standard agreed"
and "future work".
    2.2.2 Disagree on the implementation and mark as "to discuss".

On both disagreement cases, pre-registered developers of both
toolchains would receive emails outlining the conflict and they can
discuss as much as they want until a common ground is decided, or not.
It's perfectly fine to "agree to disagree", when no "common
standard"
is reached.

Some important notes:

* No toolchain should be forced to accommodate to the standard, but
would be good to *at least* describe what they do instead, so that
users don't get surprised.
* No toolchain should be forced to keep with the agreed standard, and
discussions to migrate to a better implementation would naturally
happen on a cross-toolchain forum.
* No toolchain should be forced to implement a feature just because
the other toolchain did. It's perfectly fine to never implement it, if
the need never arises.
* No developer should be forced to follow the emails or even care
about the process. Other developers on their own communities should,
if necessary, enforce their own standards, on their own pace, that it
could, or not, agree with the shared one.

What is that different than doing nothing?

First, and most important, it will log our cross-toolchain actions.
Today, we only have two good examples of cross-interactions, and
neither are visible from the other side. When (if) we start having
more, it'd be good to be able to search through them, or contribute to
them on an ad-hoc basis, if a new feature is proposed. We'll have a
documented way of the non-standard things that we're doing, before
they go on other standards, too.

Second, it'll expose what we already have as "standard", and
enable a
common channel for like-minded people to solve problems on both
toolchains. It'll also off-load both lists of having to follow any
development, but will still have a way for those interested to discuss
and agree to a common standard.

Finally, once this "database" of implementation details is big enough,
it would be easy to spot the conflicts, and it'll serve as a good TODO
list for commoning up implementation details, or even for future
compilers to choose one or the other. Entire projects, or thesis could
be written based on them, fostering more innovation in the process.

What now?

Well, people really interested in building such a system should (for
now) email me directly. If I get enough feedback, we can start
discussing in private (or another list) about how we're going to
progress.

During the brainstorm phase, or if not enough people are interested, I
still think we shouldn't stop talking. The interaction is already
happening and it's really good, I think we should just continue and
see where this takes us. Maybe by the GNU Cauldron, enough people
would want to contribute, maybe later, maybe never. Whatever works!

To be honest, I'm already really happy with the outcome, so for me, my
target was achieved!

I will report what happens during the next few months on the GCC+LLVM
BoF, so if you're at least mildly interested, please do attend. For
those looking for a few more answers to all the questions, here's my
reply on Slashdot below. If you feel inclined to answer, please do so
*in there*, not here.

http://developers.slashdot.org/comments.pl?sid=4769281&cid=46209457

Warmest regards!

--renato

On Feb 11, 2014, at 10:59 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> Hi Folks,
> 
> First of all, I'd like to thank everyone for their great responses and
> heart warming encouragement for such an enterprise. This will be my
> last email about this subject on these lists, so I'd like to just let
> everyone know what (and where) I'll be heading next with this topic.
> Feel free to reply to me personally, I don't want to span an ugly
> two-list thread.
Renato, thank you for spearheading this, but please do not cross post to both
lists like this.  Among other problems it is a severe pain for moderation.

I’m a fan of your goals, but I’d like to point out that we have already solved
this problem in various ways.  For example, C++ ABI issues are dealt with quite
well across GCC, LLVM, and many other compilers on the “itanium” ABI mailing
list.  It’s a great example of a list hosted in a “neutral” place that many
compiler vendors are on, including commercial ones.

Why don’t you just set up a few similar mailing lists to cover related topics
(toolchain topics, language extensions, etc) and encourage the right people to
join them?  I feel like you’re turning a simple problem into a complex one.

-Chris