Announcement

Collapse
No announcement yet.

Patches Posted For GCC LTO Optimizing The Linux Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Patches Posted For GCC LTO Optimizing The Linux Kernel

    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

  • #2
    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.

    Comment


    • #3
      Originally posted by dimko View Post
      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.

      Comment


      • #4
        Originally posted by oleid View Post

        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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.

            Comment


            • #7
              Originally posted by dimko View Post
              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.

              Comment


              • #8
                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.

                Comment


                • #9
                  Originally posted by dimko View Post
                  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.
                  Last edited by ryao; 14 November 2022, 10:21 PM.

                  Comment


                  • #10
                    Originally posted by cb88 View Post
                    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.

                    Comment

                    Working...
                    X