Developers Keep Striving To Build The Linux Kernel With LLVM Clang

[phoronix]

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

[edoantonioco]

Seems to be it is not an easy job, but the final result will be interesting.

[Uqbar]

They will hardly succeed

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.

[erendorn]

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?

[cb88]

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?

You'd have to write a benchmark to target each of the patched areas... normal benchmarks may not show any differences but some people probably need the proformance provided by these optimizations.

[Daktyl198]

You'd have to write a benchmark to target each of the patched areas... normal benchmarks may not show any differences but some people probably need the proformance provided by these optimizations.

These "optimizations" are non-standard C code (GCC specific). I would rather have standardized C code than relying on a single compiler that creates a subset of C...
Yes, performance matters, but so does keeping everything Open and giving people a choice in what software they use (compilers included)

[chinoto]

These "optimizations" are non-standard C code (GCC specific). I would rather have standardized C code than relying on a single compiler that creates a subset of C...[...]

Wouldn't it be superset? A subset would be more compatible with other compilers.

[Szzz]

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?

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.

[Daktyl198]

Wouldn't it be superset? A subset would be more compatible with other compilers.

Yes, thanks for that correction. I often forget about the word "superset"

[carewolf]

These "optimizations" are non-standard C code (GCC specific). I would rather have standardized C code than relying on a single compiler that creates a subset of C...
Yes, performance matters, but so does keeping everything Open and giving people a choice in what software they use (compilers included)

You can not write a kernel with standard C. The only reason Clang can even build it with these patches is because they already have support for most GCC extensions.