Patches Posted For GCC LTO Optimizing The Linux Kernel

[phoronix]

Phoronix: Patches Posted For GCC LTO Optimizing The Linux Kernel

Since last year when building the Linux kernel using LLVM's Clang compiler it's been possible to enable link-time optimizations (LTO) for the kernel build. Building the Linux kernel with GCC has lacked LTO support while a patch series posted today is the latest attempt to make that happen...

https://www.phoronix.com/news/GCC-LTO-Linux-2022

[dimko]

What works faster currently, LLVM compiled kernels or GCC ones? if differences are negligible for GCC, and it is still faster that Clang, than I don't see point of using LLVM in the first place.

[oleid]

if differences are negligible for GCC, and it is still faster that Clang, than I don't see point of using LLVM in the first place.

It's always good to compile your codebase with different compiles. You get different warnings and at times different behavior. Fixing different behavior and the warnings improves code quality.

[dimko]

It's always good to compile your codebase with different compiles. You get different warnings and at times different behavior. Fixing different behavior and the warnings improves code quality.

Well, I am a gentoo user, I am not a dev. So for me executable speed is only thing that matters. What dev develops app on, doesn't bother me, as long as portage can compile it and I can run it.

[sdack]

While the sum of performance gains may be insignificant do I recall that back when Andi Kleen introduced his work did it show some significant gains in the networking code. This would be interesting to see if it remains true or if it has changed. Another area of interest would be io_ring with all the tuning that went into it. If Phoronix is going to run LTO kernel benchmarks then these two areas are what would interest me the most.

[ms178]

Ouch, the GCC-LTO patchset did get some heavy flak from other devs for the lack of improvements and too much hacks/complexity for no gain. At least some performance improvements would be welcome, but weren't observable with it.

dimko Try out both, a Kernel build does not taking too long to finish. As I've used both GCC and Clang/LTO with some advanced flags but wasn't able to spot too many differences. I keep using the Clang/FullLTO-Kernel though as it is a bit smoother for me, and I hit some strange compile issues with GCC lately.

[AlDunsmuir]

What works faster currently, LLVM compiled kernels or GCC ones? if differences are negligible for GCC, and it is still faster that Clang, than I don't see point of using LLVM in the first place.

Supporting both toolchains helps bringing up a new architecture. Previously GCC support was mandatory, even if it was not the primary compiler for that architecture.

[cb88]

Something is wrong with that if the kernel ended up larger due to inlining... that's exactly the opposite of how that is supposed to work.

[ryao]

What works faster currently, LLVM compiled kernels or GCC ones? if differences are negligible for GCC, and it is still faster that Clang, than I don't see point of using LLVM in the first place.

The numbers were for GCC built Linux vs GCC + LTO built Linux. They were not a Clang versus GCC comparison.

That being said, the kernel is likely to block waiting on IO, so the compiler does not really matter very much as far as performance is concerned. However, building kernels with multiple compilers can improve code quality by highlighting subtle bugs that the different compiler’s diagnostics catches.

LLVM/Clang also has a stronger focus on correctness over GCC in my opinion given that it has a much cleaner codebase, which should materialize as fewer issues from compiler bugs. Also, unlike GCC, LLVM is not trying to hide just how bad its code quality is as measured by Coverity:

https://scan.coverity.com/projects/llvm

https://scan.coverity.com/projects/gcc

There is no legitimate reason to do that and doing it goes against the spirit of open source. It is also pointless since anyone can fork GCC on GitHub and submit a GCC build to Coverity to see all of the potential issues.

[xorbe]

Something is wrong with that if the kernel ended up larger due to inlining... that's exactly the opposite of how that is supposed to work.

Inlining duplicates the called function locally ... duplicating code doesn't usually shrink anything. But it avoids a call/ret pair and hence avoids 2 possible branch mispredicts/stalls.