Originally Posted by
elanthis
Long Version
Clang is a superior compiler frontend. Whether or not LLVM is a superior backend (by "speed benchmark" standards it is not, yet; there are other reasons one might prefer it, however), Clang is faster to compile, tends to provide better diagnostics (GCC did some catching up after being slapped in the face with how awful its diagnostics were, but Clang isn't sitting still), Clang MUCH easier to extend and improve, has fantastic analysis tools, and has been explicitly built to be reused as a higher-level tool aside from simply compiling code into assembler.
GCC has tons of cruft and is difficult to work with; this has led to a general problem gaining new contributors, a slow exodus of existing developers (especially to Clang, which is more or less feature comparable but friendlier to work on), and requires lots of expert knowledge to even make a simple bug fix (as opposed to Clang, where even a total newbie can jump in and start doing pretty interesting things pretty quickly).
Part of this is a very explicit difference in design. GCC is an integrated whole that is not intended to be separable at all. Very very explicitly, in fact, and not for _any_ technical reason: it was because RMS was afraid that if the GCC frontend and GCC backend were usable independently, then evil vile horrible proprietary companies might use one or the other with a proprietary tool. Clang, on the other hand, was designed with full knowledge of the fact that the absolute least important thing that a compiler frontend can be used for in this day and age is the actual compilation. All the real action -- all the work that saves developers times and makes them enjoy their job -- takes place in higher level development tools, which require deep language integration. Given the huge complexity of C++, very few such tools have been developed, and most of them are quite flawed. (Visual Assist X generally is considered the best of such tools, and as a frequent user, I can attest to how often it screws up and pissed me off; compare to modern Java or C# environments where the tools are more or less perfect.) Clang allows more such tools to be written (particularly, FOSS tools, which do not currently compete favorably with their proprietary rivals) and allows them to have an excellent understanding of the language -- the exact same understanding of the language as the compiler itself, in fact.
Being able to compile the code is thus secondary to Clang's real strength. It's still important, however, since there are some features Clang enables that GCC frowns upon (easy injection of user-specified code in the appropriate places for application-specific instrumentation, for example), and additionally because you can't be sure your frontend actually works 100% correctly if you aren't using it to generate working code (since the only way to know that your model of the code is correct is to run the code's test cases, which require it to be compiled).
Also, LLVM is possibly going to be faster than GCC in the future. Given the rate of change between the two projects, it's quite likely that'll happen, assuming LLVM development doesn't start to drastically slow down or GCC drastically speed up. While it's true there aren't a lot of low-hanging fruit left for LLVM in terms of performance, there's still a lot of opportunities for it to match and then pull ahead of GCC, and it's simply easier to write those optimization for LLVM's framework than it is to write them for GCC's. That is, again, very valuable if you're a compiler developer.
There's also features that LLVM itself provides that GCC does not. LLVM has a JIT mode, which has been used for some very interesting things (like a massively updated and more complete CINT). LLVM has a very interesting IR model, which has allowed for projects like Portable NaCl which would otherwise be incredibly difficult to pull off. I'm unsure what if any benefits there are for kernel developers, but there are certainly a good number of them for userspace developers.
Shot Version
The key goal of Clang is to support tools like fully accurate code completion, large-scale invasive automatic refactoring support, highly detailed static analysis, semantic and structural analysis for automatic documentation/binding generation, user customizable instrumentation and code morphing, and so on. Being able to use even just one of those tools when developing the kernel makes it entirely worth ensuring that Clang/LLVM are capable of fully and correctly parsing (and then compiling) the kernel source code.
This folks is the reason not to sniff glue and/or huff paint, its makes you believe and say things that are not true.
Reply With Quote
