Re: LLVM collaboration?

[Andrew Pinski <pinskia at gmail dot com>]

On Fri, Feb 7, 2014 at 1:33 PM, Renato Golin <renato.golin@linaro.org> wrote:
> Folks,
>
> I'm about to do something I've been advised against, but since I
> normally don't have good judgement, I'll risk it, because I think it's
> worth it. I know some people here share my views and this is the
> reason I'm writing this.
>
>
> The problem
>
> For a long time already I've been hearing on the LLVM list people
> saying: "oh, ld should not accept this deprecated instruction, but we
> can't change that", "that would be a good idea, but we need to talk to
> the GCC guys first", and to be honest, nobody ever does.

Well you should also be talking to the binutils folks for ld issue.
GCC is less an issue here.


>
> Worst still, with Clang and LLVM getting more traction recently, and
> with a lot of very interesting academic work being done, a lot of new
> things are getting into LLVM first (like the sanitizers, or some
> specialized pragmas) and we're dangerously close to start having
> clang-extensions, which in my humble opinion, would be a nightmare.
>
> We, on the other side of the fence, know very well how hard it is to
> keep with legacy undocumented gcc-extensions, and the ARM side is
> particularly filled with magical things, so I know very well how you
> guys would feel if you, one day, had to start implementing clang stuff
> without even participating in the original design just because someone
> relies on it.

Can you give an example?  We have been cleaning these undocumented
extensions.  I think this is not a big issue but without examples, it
is harder to figure out what needs to be done.

>
> So, as far as I can see (please, correct me if I'm wrong), there are
> two critical problems that we're facing right now:
>
> 1. There IS an unnecessary fence between GCC and LLVM.

I don't see that.  What I see a GCC folks are working on GCC and the
rest of the GNU tools (including glibc) but the LLVM only work on LLVM
and when they find an issue they don't bring it up to the GCC list.

>
> License arguments are one reason why we can't share code as easily as
> we would like, but there is no argument against sharing ideas,
> cross-reporting bugs, helping each other implement a better
> compiler/linker/assembler/libraries just because of an artificial
> wall. We need to break this wall.
>
> I rarely see GCC folks reporting bugs on our side, or people saying
> "we should check with the GCC folks" actually doing it. We're not
> contagious folks, you know. Talking to GCC engineers won't make me a
> lesser LLVM engineer, and vice-versa.

That is because most of us don't need to figure out what LLVM is doing
for most of the time.   It should be up to the people who say check
with the GCC folks first to actually ask the GCC folks rather than the
other way around to figure out what LLVM needs.

>
> I happen to have a very deep respect for GCC *and* for my preferred
> personal license (GPLv3), but I also happen to work with LLVM, and I
> like it a lot. There is no contradiction on those statements, and I
> wish more people could share my opinion.
>
> 2. There are decisions that NEED to be shared.
>
> In the past, GCC implemented a lot of extensions because the standards
> weren't good enough. This has changed, but the fact that there will
> always be things that don't belong on any other standard, and are very
> specific to the toolchain inner workings, hasn't.

It depends on the extensions.  Most of people working on GCC are
working on GCC because that is the only compiler they need to work on;
LLVM is not even in most of their minds when they bring up an
extension.

An good example is asm goto, it is brought up by the Linux kernel
folks to the GCC folks.  Us as a project should not say please also
bring it up to the clang folks for discussion  GCC should implement a
good extension which is useful for the kernel folks.  The same is true
of the ifunc extension, it was brought up by the glibc folks to GCC.

>
> It would be beneficial to both toolchains to have a shared forum where
> we could not only discuss how to solve problems better, but also keep
> track of the results, so we can use it as guidelines when implementing
> those features.

Again it depends on the issue.  I don't some issues don't need an
extra discussion list and in fact get in the way of implementing
features.

>
> Further still, other compilers would certainly benefit from such
> guidelines, if they want to interact with our toolchains. So, this
> wouldn't be just for our sake, but also for future technologies. We
> had a hard time figuring out why GCC would do this or that, and in the
> end, there was always a reason (mostly good, sometimes, not so much),
> but we wasted a lot of time following problems lost in translation.
>
>
> The Open Source Compiler Initiative
>
> My view is that we're unnecessarily duplicating a lot of the work to
> create a powerful toolchain. The license problems won't go away, so I
> don't think LLVM will ever disappear. But we're engineers, not
> lawyers, so we should solve the bigger technical problem in a way that
> we know how: by making things work.
>
> For the last year or two, Clang and GCC are approaching an asymptote
> as to what people believe a toolchain should be, but we won't converge
> to the same solution unless we talk. If we keep our ideas enclosed
> inside our own communities (who has the time to follow both gcc and
> llvm lists?), we'll forever fly around the expected target and never
> reach it.

I don't see a reason why you really should not bring these issues up
to the list that are proposing the extension in the first place like
the LKML since the current new extension are being added to support
the kernel rather than anything else.  I don't think it should be
another list to solve problems that are can be solved at the source
rather.

Thanks,
Andrew Pinski

>
> To solve the technical problem of duplicated work we just need to
> start talking to each other. This mailing list (or LLVM's) is not a
> good place, since the traffic is huge and not every one is interested,
> so I think we should have something else (another list? a web page? a
> bugzilla?) where we'd record all common problems and proposals for new
> features (not present in any standards), so that at least we know what
> the problems are.
>
> Getting to fix a problem or accepting a proposal would go a long way
> of having them as kosher on both compilers, and that could be
> considered as the standard compiler implementation, so other
> compilers, even the closed source ones, should follow suit.
>
> I'll be at the GNU Cauldron this year, feel free to come and discuss
> this and other ideas. I hope to participate more in the GCC side of
> things, and I wish some of you guys would do the same on our side. And
> hopefully, in a few years, we'll all be on the same side.
>
> I'll stop here, TL;DR; wise. Please, reply copying me, as I'm not
> (yet) subscribing to this list.
>
> Best Regards,
> --renato