Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

[Imouto]

Also, GCC gets some of its speed by doing optimizations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)

Well, I am totally pro-GCC. At the same time, I don't mean LLVM is bad. The fact that LLVM is hanged on Apple is bad though.

Why I think GCC is better even though its optimization is buggy?
1) That GCC does wrong optimization does not mean other compilers don't.
How about a compiler that does not do optimization? That would be like that 0-CPU-kernel April fools joke. Sure we can make a computer secure by removing optimization. we can also remove c language as well, to prevent optimization error as well as programmer's run-time error. What I want to say is removing the optimization is not a solution, but a regression. Furthermore, history tells us such compilers should still have bugs.
2) GCC is extensively used on all systems. It is no surprising that we find a bug in it, just like any other programs. However, even when it is been so extensively used, yet we rarely find bugs in it. This is a solid proof that it is, surprisingly, bug-proof.
3) A lot more bugs are produced not by optimization, but by programmers themselves. So who should be blamed more?

[Nobu]

It's a programmer that made the optimization in the first place, so obviously a programmer get's the blame. However, it's not always the fault of someone writing for (e.g.) the Linux kernel that should be blamed for an optimization that was written into the compiler. How many optimizations have been put into gcc since the first stable release? Do you expect everyone who compiles code with gcc to know about all those optimizations?

On the other hand, you can't expect everyone who writes compiler optimizations to know every consequence of the optimization on every piece of code that's ever compiled and touches that code-path. There could be any number of variations of code that use the optimization without a single bug appearing, but just one that uses it (correctly) and produces a bug for no apparent reason.

That is why a zero-optimized build (which you can do with gcc too, btw) is useful: it allows you to catch bugs in code that are caused solely by optimizations, and whose root may be in the compiler itself. clang/llvm can be useful in a similar way: If it's written well, it can be used to find bugs (in the compiler or the program itself) which prevent a program from compiling correctly in gcc.

[Balthazar]

While I can see many of the comments here are strongly biased, there should be no real doubts about the benefits of clang. Because it is a more modern, modular compiler, it offers amazing advantages during development. The IDE easily, continuously, checks all the syntax for you, and have great suggestions on how to fix it. Every single thing the compiler understands, the IDE understands too. This is truly great for the developer and developers of IDE's and various programming tools. Your programming just goes incredibly much faster because of this. So it's far more than a toy. Too bad then, that there are so many more developers behind gcc than clang. If all those gazillions of working hours total spent on developing for gcc were spent on clang instead, that would be truly awesome. Perhaps it is suffering from the fact that Apple associated their name too closely with the project... but then again, if they didn't, clang would probably just be some little-known curiousity for die-hard nerds. I see that the main performance difference is because of lacking support for OpenMP in clang. Considering that clang is a relatively new project making incredibly rapid progress, I wouldn't be too surprised if they catch up soon. Time will tell, but clearly the gcc team is much bigger than the clang team.

[garytr24]

You guys have a really narrow viewpoint about LLVM. It's a compiler *framework* that just happens to also compile C/C++ code pretty well. But its existence isn't justified by only that capability. It's relatively easy to make a front-end for its intermediate representation, which is what I did for a compilers course. But you can go as deep as you need. It's going to have a far-reaching effect that's much more powerful than compiling old C code 10% faster. There are many examples of what it enables, here's one: http://vmkit.llvm.org/

[XorEaxEax]

Well, just to be clear, Clang is the frontend (C-language frontend) and came much later than LLVM (for a long time LLVM used GCC as frontend and still can by using the dragonegg plugin), also Clang comes directly from Apple, while LLVM originated in academia.

As for the modularity and it's possible 'symbiosis' with the IDE, it certainly offers these features but sofar I've only seen them employed in the proprietary XCode which severely limits it's overall potential (and having suffered through a weekend with XCode when helping a friend port some software to his Mac, I'm NOT impressed with it, it was slow and crashed and sometimes just hung and you couldn't even kill it!?, granted this is was not likely due to any integration with clang but after hearing how great XCode supposedly is I just had to get this rant out, sorry). Anyway, as it stands I don't know of any other IDE which integrates to Clang, nor do I know of any which is in development so the integration buzzword means very little outside the Apple realm as of now. Hopefully we will see some such solution emerge (or maybe I've just missed it?) as integration between ide and frontend certainly has benefits.

While I can see many of the comments here are strongly biased

So are yours, so why even point to bias at all?

I see that the main performance difference is because of lacking support for OpenMP in clang.

Yes in these benchmarks it is, however I see an overall difference of 5-15% even in software which doesn't rely on openmp.

Considering that clang is a relatively new project making incredibly rapid progress, I wouldn't be too surprised if they catch up soon.

Well, relative to GCC it certainly is, still it's been around since atleast 2005 (Apple didn't open source it until 2007 though) so it's not exactly 'new'. As for the catching up thing, I've been hearing that even since clang was first released, and I've seen no indication of the performance gap closing. But like I said earlier in this thread, that doesn't mean it won't, it may trounce GCC in optimization in the coming years, or GCC might increase the gap even further. Personally I'm interested in what performance I get out of the compiled code _now_, I can always switch compiler later (and for the record, I use both of them at work and home and although GCC has gotten much better in it's error reporting I certainly still hold Clang/LLVM higher in that regard).

But its existence isn't justified by only that capability. It's relatively easy to make a front-end for its intermediate representation,

Agreed, I'd actually say that as far as the open source ecosystem in general, it's existance is already justified by how often it is used to build JIT compilers for a great variety of targets. However it's usefulness as a JIT framework doesn't mean it's the best choice as a static compiler, and sofar it lags behind GCC in many areas such as supported architectures, languages and as already mentioned performance of generated code.

There seems to be a tendency amongst the clang/llvm advocates of wanting GCC to more or less disappear (not pointing at you) which to me is just insane, just as the notion that clang/llvm should disappear which seems mainly to be the result of deep distrust towards Apple (that distrust is warranted imo but that doesn't take away from llvm's usefulness). We are enjoying the best possible situation now where we have two really strong open source free compiler toolchains/frameworks which are engaging in friendly competition, why would we ever want that to change? Ok so it could be better if there was even more competition, maybe path64 (ekopath)?.