Developers Keep Striving To Build The Linux Kernel With LLVM Clang

[behanw]

Clarifying what clang is

At least sounds scary to me: dynamically changing execution paths at the kernel level.
Anything that could go wrong, will gain new interesting ways to badly fail.
In my opinion.

There are no "dynamically changing execution paths". clang is a C compiler like gcc. The LLVMLinux project makes changes to both clang/llvm and the kernel so that the kernel can be compiled with clang. The issue is that the kernel depends on a lot of gnu extensions to C which aren't necessarily supported by clang, and that both clang and the kernel are moving targets.

[behanw]

How do the patches affect performance?
I guess GCC can compile the patched version too, so maybe someone can benchmark the vanilla vs patched kernel (both compile by gcc with same options) to see if there is a reason not to upstream the patches?

The point of the project is to enable a choice of toolchains. Some people find clang an easier toolchain to work with, others like using the LLVM-IR to analyse code. Other people prefer the BSD license over the GPL. There are lots of reasons why clang/llvm are an interesting alternative to gcc. Personally I like the idea that competition between the toolchains means better features in both for all developers.

No one I know is interested in clang specifically for performance reasons. Though in general if you look at the phoronix benchmarks you can see that clang is better than gcc in some areas and worse in others. On average they currently perform similarly, though gcc has been optimized for many years, and clang is still relatively young with a lot more optimizations to come.

Like I said: toolchain competition is good for all developers.

[behanw]

I think the main reason to not include these patches is because they will make code uglier. Linux uses some gcc extensions which clang doesn't support. Linux devs don't want to rewrite code in standard c and clang devs don't want to support these extensions. At least this is what I remeber from previous Phoronix articles/discussions.

Actually, most of our patches arguable make the code better. Certainly that is the feeling I've got from most kernel devs I spoken to. The LLVMLinux project is certainly trying to make the code better.

The only place where one might argue to the contrary is with Variable Length Arrays In Structs, and even in those situations the new code isn't that bad. The big problem with using VLAIS is that it is explicitly disallowed by the C standards. Using it actually dramatically affects all the code around it, and can make higher level compiler optimizations much harder to do. For instance, sizeof(struct_with_vlais) is no longer constant, and offsets to structure members of struct_with_vlais need to be dynamically calculated at run time. One could argue that changing the code to use flexible members (zero length arrays at the end of the struct) with some pointer math makes it much clearer what is actually going on.

[behanw]

Phoronix: Developers Keep Striving To Build The Linux Kernel With LLVM Clang

With another Linux Foundation Summit means another time to hear an update about LLVMLinux, the Linux Foundation backed project to build the mainline Linux kernel with LLVM's Clang C/C++ compiler in place of GCC...

http://www.phoronix.com/vr.php?view=MTY0NDg

One last thing. The URL to get to my slides in the article sadly is wrong. You can find them here: http://events.linuxfoundation.org/si...-LLVMLinux.pdf

If anyone has questions, please feel free to ask them on the LLVMLinux mailing list or OFTC #llvmlinux IRC channel.

[erendorn]

The point of the project is to enable a choice of toolchains. Some people find clang an easier toolchain to work with, others like using the LLVM-IR to analyse code. Other people prefer the BSD license over the GPL. There are lots of reasons why clang/llvm are an interesting alternative to gcc. Personally I like the idea that competition between the toolchains means better features in both for all developers.

No one I know is interested in clang specifically for performance reasons. Though in general if you look at the phoronix benchmarks you can see that clang is better than gcc in some areas and worse in others. On average they currently perform similarly, though gcc has been optimized for many years, and clang is still relatively young with a lot more optimizations to come.

Like I said: toolchain competition is good for all developers.

Well that's not at all what I was talking about. I wondered about a gcc vs gcc comparison. With patches standard code versus gcc extension code.