Announcement

Collapse
No announcement yet.

LTO'ing LibreOffice With GCC 6

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

  • LTO'ing LibreOffice With GCC 6

    Phoronix: LTO'ing LibreOffice With GCC 6

    Upstream GCC developer Jan Hubička has written about his experience compiling LibreOffice with GCC6 -- while also making use of Link-Time Optimizations (LTO) -- and comparing various criteria against that of other GCC and LLVM/Clang compiler versions...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I've always wondered, why binary distros never provide packages compiled with LTO. Even critical to performance ones, like Mesa, Xorg, browsers…

    Comment


    • #3
      Probably for the same reason they don't provide packages compiled with profile-assisted optimizations, not even for packages with good performance tests.

      That the sources don't make it easy or default

      Comment


      • #4
        Originally posted by Hi-Angel View Post
        I've always wondered, why binary distros never provide packages compiled with LTO. Even critical to performance ones, like Mesa, Xorg, browsers…
        Enabling LTO is not completely transparent and thus it requires some extra effort (I would say not that harder than switching to new compiler release). It is up to the the upstream developers to switch to LTO rather than relying on packagers of each distro to do so. To make this happen LTO needs to be cheap, transparent and reliable enough. It also needs bring enough benefits to make the effort adding -flto and fixing the fallout worth it.

        These days one of remaining issues blocking widespread usage of LTO are the debug info issues.

        Comment


        • #5
          Also LTO is actually one of the more difficult optimizations to enable, it can reveal tons of bug that didn't manifest before. Often you are saved by function boundaries causing register copies of variables to be flushed, but once things are inlined across entire libraries, you run into issues like shared variable not declared volatile (they stay in registers and will never be updated in the other thread), strict aliasing: The compiler will use aliasing rules to keep things in differnt registers that should never share adress, but if you did a bad type-case.... you might find variables in even the same thread not getting updated like they used to.

          And finally when you compiled some files with expanded instructions sets (AVX specific functions for instance), they used to spill into places they shouldn't due to global common code deduplication, but that should be solved in GCC 5 already.

          So LTO works great if you have no bugs, but it can reveal a lot of bugs. Including compiler bugs.

          Comment


          • #6
            Originally posted by carewolf View Post
            Also LTO is actually one of the more difficult optimizations to enable, it can reveal tons of bug that didn't manifest before. Often you are saved by function boundaries causing register copies of variables to be flushed, but once things are inlined across entire libraries, you run into issues like shared variable not declared volatile (they stay in registers and will never be updated in the other thread), strict aliasing: The compiler will use aliasing rules to keep things in differnt registers that should never share adress, but if you did a bad type-case.... you might find variables in even the same thread not getting updated like they used to.

            And finally when you compiled some files with expanded instructions sets (AVX specific functions for instance), they used to spill into places they shouldn't due to global common code deduplication, but that should be solved in GCC 5 already.

            So LTO works great if you have no bugs, but it can reveal a lot of bugs. Including compiler bugs.
            I can see this if LTO is used on the kernel...there'd be a total mess that would take ages to find, debug, and rewrite. If compiler errors are found as a result of LTO usage that would be a great thing so that these insidious compiler bugs can be fixed.

            Will judicious use of LTO improve the performance of code?

            Comment


            • #7
              Originally posted by carewolf View Post
              And finally when you compiled some files with expanded instructions sets (AVX specific functions for instance), they used to spill into places they shouldn't due to global common code deduplication, but that should be solved in GCC 5 already.

              So LTO works great if you have no bugs, but it can reveal a lot of bugs. Including compiler bugs.
              If you mean ICF, it never really merged functions compiled with different instruction sets. Before GCC 5 the optimization option handling was sloppy: at compile time the optimization options used was applied, at link time the compilation continued with options passed to linker. GCC 5 fixes that. I am not quite sure of the situation in LLVM. LLVM 3.5 behaved in similarly broken way but there was some efforts to fix that.

              I would say that switching to LTO should be done by upstream developers rather then relying on package maintainers of individual distros to do the job. Once LTO is part of daily development, the previously latent bugs will be found and fixed.

              Comment


              • #8
                Originally posted by DeepDayze View Post
                Will judicious use of LTO improve the performance of code?
                Yes, definitely. You can see an example in the article in whose comments we're discussing. In general, it does pretty much all optimizations, that compiler usually does — but across object files. The problem with them, is that without LTO it is impossible to make analysis across all of them, thus removing unnessary functions, unnessary code, reducing memory usage, etc. Without LTO optimizations are only done in each object file separately.

                It can even do things like removing unused undefined references.
                Last edited by Hi-Angel; 19 March 2016, 04:56 PM.

                Comment


                • #9
                  Originally posted by Hi-Angel View Post
                  Yes, definitely. You can see an example in the article in whose comments we're discussing. In general, it does pretty much all optimizations, that compiler usually does — but across object files. The problem with them, is that without LTO it is impossible to make analysis across all of them, thus removing unnessary functions, unnessary code, reducing memory usage, etc. Without LTO optimizations are only done in each object file separately.

                  It can even do things like removing unused undefined references.
                  Hopefully this will be the default compiler flag for compiling kernels. If any patches are needed to the kernel to make LTO work, then it should happen! Getting as much performance out of code should be a good thing, especially for older or low-resource systems (embedded).

                  Comment


                  • #10
                    Originally posted by hubicka View Post
                    These days one of remaining issues blocking widespread usage of LTO are the debug info issues.
                    Debug info? I think, optimizations usage in debug builds is quite rare — unless someone debugging a bug introduced by optimizations. I mean, it is, of course, useful, but I wouldn't call it a blocker for widespread.

                    Comment

                    Working...
                    X