LLVM 2.8 is available

Posted Oct 11, 2010 8:25 UTC (Mon) by nix (subscriber, #2304)
In reply to: LLVM 2.8 is available by daglwn
Parent article: LLVM 2.8 is available

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.