LLVM 2.8 is available

Posted Oct 11, 2010 1:57 UTC (Mon) by mlopezibanez (guest, #66088)
In reply to: LLVM 2.8 is available by daglwn
Parent article: LLVM 2.8 is available

* The FSF would never accept such a thing. They perceive Apple as hostile to free software, and LLVM/Clang as a way to circumvent the patent and drm protections of GPLv3. It doesn't matter whether this is wrong or right, they won't accept LLVM/Clang integrated into GCC unless the copyright is assigned to the FSF.

* The GCC FE maintainers won't accept Clang and won't work on integrating it in GCC. See http://gcc.gnu.org/ml/gcc/2010-09/msg00326.html.

* Some GCC middle-end maintainers have expressed interest in Clang but they didn't accept LLVM when it was offered to the FSF (did you know that?). They won't accept Dragonegg either because it effectively means replacing the middle-end of GCC.

* And why the LLVM people will care about GCC at all if they consider it inferior? Now that Clang supports C++, dragonegg's only purpose is to give LLVM access to the other GCC FEs.

* LLVM is effectively replacing the whole GNU toolchain. The time for integration is well past.

So the projects won't integrate. Can they co-exist?

Probably yes. The license may not be an issue for you, but it is certainly an issue for many, many people that won't contribute (or even use) LLVM because of it. It is not clear at all that GNU/Linux distros will switch to LLVM, even if LLVM reached feature parity with GCC, was able to compile the kernel, produced faster coder, and was ported to more architectures. The main reason will be the license.

On the other hand, both projects rely on corporate support (almost all devs are paid), and they will suffer without it. Despite the size of these projects, the number of devs is relatively low. If Apple decided that LLVM is good enough for them and they don't care about compiling the Linux kernel, and put the devs to work on something else, LLVM will never catch with GCC, and will never be a real alternative. Similarly, if, let's say, Novell and Google decided to reallocate some devs to support LLVM, this will rapidly reduce the current advantage of GCC over LLVM and further slow down GCC's development.

I am really curious how this will evolve, since we are just at the beginning. LLVM is not yet complete enough to be a viable alternative, but the potential and the progress are amazing and we know that a full-blown switch may happen overnight a la XFree86. On the other hand, GCC is not going to disappear any time soon, it is still much superior in some aspects, and it is slowly addressing some of its shortcomings.

But at the end, it will be an either-or choice.

LLVM 2.8 is available

Posted Oct 11, 2010 4:07 UTC (Mon) by daglwn (guest, #65432) [Link] (6 responses)

See my comment about license silliness. I think what you're missing is that the GCC maintainers and FSF don't need to "accept" anything. I think this is going to be a distribution/user-driven thing, not unlink egcs or x.org.

Dragonegg is a no-brainer. The gcc plugin infrastructure means they can't stop it. Much compiler research is rapidly shifting to the LLVM world. Dragonegg is the perfect tool for this, meaning that at least in some areas, gcc will be playing catch-up in a few years. gcc has a big advantage in the number of targets it supports. Dragonegg leverages that.

The frontend is trickier but if the gcc devs refuse to allow it to be integrated (alongside the existing frontend initially) then I think we may see a mass shift toward Clang/LLVM. User experience is very important and Joseph Myers is missing something big. With the advent of many-core and massive threading via GPUs and the like, the compiler landscape is rapidly shifting. We need much smarter, friendlier compilers. The smarts are the relatively easy part. User friendliness is a big deal and the harder problem to solve. Clang has a head start there.

One can't incrementally improve the existing gcc frontend to be as good about error-reporting as Clang. That capability is designed in from the ground up. Incremental change there is going to take years at best and by that point it will be too late.

Right now, Clang is ahead in the user experience department but that will change quickly if the project can't figure out how to integrate support for OpenMP, UPC and the like. And not just integrate it, but DRIVE it.

LLVM 2.8 is available

Posted Oct 11, 2010 8:25 UTC (Mon) by nix (subscriber, #2304) [Link] (5 responses)

You do realise that it looks very silly to sit there and tell actual GCC developers that you know what GCC developers think better than they do?

LLVM is a really nifty project, granted, but you haven't addressed *any* of the points Manuel just made. It might be a 'distribution-led thing', but do you really want *compiler* fragmentation between distros? I doubt the distros do either, and it'll be a long time before RH in particular switches away from GCC, because of the deep pool of GCC expertise at RH (originally thanks to the Cygnus acquisition, but they've kept it alive since then).

Oh, and one *can* incremnetally improve the existing GCC frontend to be as good at error-reporting as clang. Major incremental error-reporting improvements have happened in GCC already (e.g. column-number reporting, only turned off to avoid confusing interface tools IIRC).

And, uh, sorry to burst your bubble but user friendliness is not by *any* stretch of the imagination the hardest problem in compiler development. Really, really not.

LLVM 2.8 is available

Posted Oct 11, 2010 13:15 UTC (Mon) by daglwn (guest, #65432) [Link] (4 responses)

There is no such thing as compiler fragmentation. ABI standards ensure that. What we might have is library fragmentation, due to libstdc++/libc++ incompatibilities in internal implementation since there is no standard library ABI.

I don't claim to know what gcc developers think. I'm simply going on the basis of the links posted and various threads I've read.

Column-number reporting is a really simple change. Much harder is knowing what to report, when to keep going and when to stop. AFAIK gcc has never really improved that for C++. Minor error formatting changes don't really improve the situation.

As far as the "hardest" problem goes, it depends on how one defines "hard." Certainly the aliasing/dependence analysis problem is one of the hardest to tackle in terms of analyzing program semantics. But the problem is well understood and various solutions of various complexity and cost are known. Diagnostics and error-reporting is a much less formalized thing. There's much less general understanding of how to do it well. That's what I meant by "hard." It's harder to come up with creative new solutions than to implement well-known ones. The fact that no compiler I know of really does it well (though QOI varies tremendously) is testament to its difficulty.

I'm not trying to knock gcc, just expressing my own observations over years of compiler development. Clang/LLVM has its own deficiencies which should be addressed and I've touched on some of them. But I believe the Clang/LLVM development path is clearer and much more accessible, meaning that it has a better chance (for now) of rapid improvement.

LLVM 2.8 is available

Posted Oct 11, 2010 14:19 UTC (Mon) by mlopezibanez (guest, #66088) [Link] (2 responses)

I have tried quite unsuccessfully to improve GCC diagnostics, (I was among the ones that worked on enabling column numbers by default, and it was a lot of work), so you don't have to convince me how bad the situation is. If you care about diagnostics, the gap between GCC and Clang is *abysmal*.

But you are missing some important points:

* Licenses are important to many.

* LLVM is not near ready to be used as the compiler of choice of any Linux distro. It is a matter of time you say, yes, probably, but who will be working on this? Apple?

* Diagnostics are important for users and for Apple, but not for the employers of GCC maintainers, not for the customers of the employers, and not enough for any critical mass of volunteer developers to step up and improve the situation in GCC during the last two decades.

You are right on a few things:

* The potential of the LLVM project is immense and the pace of development incredible, so my understanding is that the competition has not really even started yet.

* The competition from LLVM is *very* good for GCC. and the achievements of LLVM have been already used as arguments by GCC maintainers when dealing with the FSF.

I wish LLVM lowered the level of fanaticism, FSF/GPL/GNU-hating, and hype to be able to convince GCC maintainers that there are ways to improve GCC. This is a useful comparison: http://people.redhat.com/bkoz/diagnostics/diagnostics.html

This is just a well-dressed lie: "LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster." http://developer.apple.com/technologies/tools/whats-new.h...

My hope is that a fair and healthy competition will convince GCC maintainers that change is needed, that a different GCC is possible, and it will attract new GCC devs pushing for such changes. The main threat to GCC's future is not LLVM, it is its own inertia.

LLVM 2.8 is available

Posted Oct 11, 2010 14:57 UTC (Mon) by daglwn (guest, #65432) [Link]

Diagnostics are important for users and for Apple, but not for the employers of GCC maintainers, not for the customers of the employers, and not enough for any critical mass of volunteer developers to step up and improve the situation in GCC during the last two decades.

My argument is that we're at a technological inflection point. The rules have changed. So past history is not a predictor of future results. Once people start compiling programs that use thousands or millions of threads, they will want good diagnostics. Not just about syntax errors but about why this or that piece of code won't parallelize. It's not just the compiler that will have to change. We're going to need an entirely new programming ecosystem, one able to analyze runtime behavior and feed it back to the user to improve the program.

I wish LLVM lowered the level of fanaticism, FSF/GPL/GNU-hating

I agree with you on this. It's one of the blind spots that needs to be corrected.

This is just a well-dressed lie: "LLVM is fast. It compiles code twice as quickly as GCC, yet produces final applications that also run faster

Also agreed. I think there's parity right now. LLVM's focus really isn't code quality and that's ok for now.

The main threat to GCC's future is not LLVM, it is its own inertia.

Exactly right. LLVM is the agent exposing that problem, which is why it doesn't have to be either-or. Neither project need incorporate code from the other (and indeed the code can only flow one way currently) but I think there's something to be gained from cooperation, much more than from "healthy competition."

LLVM 2.8 is available

Posted Oct 11, 2010 15:04 UTC (Mon) by daglwn (guest, #65432) [Link]

LLVM is not near ready to be used as the compiler of choice of any Linux distro. It is a matter of time you say, yes, probably, but who will be working on this? Apple?

For time time being, yes, along with plenty of non-Apple people. There's a bug tracking it.

I believe that LLVM has an Apple problem. There's a widespread perception out there that Apple controls everything that happens with LLVM. There are lots of non-Apple people working on LLVM and their work is not in any way dictated by Apple. However, there are certain problems with the way Apple controls things. Foremost among them is keeping some bugs in an internal Apple bug database, with only cryptic references to rdar//this-or-that in commit messages. This opaqueness is a big problem and it's not just limited to the bug database

In order to grow more quickly, LLVM is going to have to shed this perception. I don't know how that will happen but I think it will involve some kind of reorganization/formalization of decision-making bodies. LLVM is approaching the point where the project will need more formal processes than it has now. I believe that's the big hurdle for LLVM and it's a difficult one.

LLVM 2.8 is available

Posted Oct 11, 2010 22:47 UTC (Mon) by nix (subscriber, #2304) [Link]

Ah, I think we're in violent agreement then. I just misunderstood you.

LLVM 2.8 is available

Posted Oct 11, 2010 14:28 UTC (Mon) by andrel (guest, #5166) [Link]

I'm surprised you argue distros wouldn't switch because of the license, even if LLVM were to offer clear technical advantages over GCC. I predict that as soon as it becomes possible to use LLVM as the primary compiler we'll see that supported as an option in Gentoo, and somebody will recompile all of Debian using it.