[RDY] Add LTO support

[zhou13]

No description provided.

[justinmk]

Is there a way to use 2.8.12? We need to be able to build on as many systems as possible.

[zhou13]

@justinmk Updated.

[justinmk]

We tried LTO in #4313 , later reverted in mgraczyk@c2b2e0e .

But it looks like you did something like what was discussed in #4313 (comment) , which was never tried.

@mhinz @Yamakaky @ZyX-I @jamessan @jszakmeister any comments/objections?

AppVeyor build had some weird failures; restarted.

[zhou13]

The new CMake policy CMP0069 has much better LTO support for compilers other than intel. It was introduced in CMake 3.9. This patch only enables LTO if both the CMake and the compiler support LTO/CMP0069.

[mhinz]

What would be the exact advantage for Neovim? Is there a benchmark that shows an improvement in any way?

Does anyone know how to check if Mach-O executable was compiled with LTO? (clang or gcc)

[jamessan]

What would be the exact advantage for Neovim?

The same sorts of advantages that come from compiling with -O2 rather than -O0, except that with LTO the compiler is able to make optimizations across translation units.

Does anyone know how to check if Mach-O executable was compiled with LTO?

There's no marker for the compiler using LTO. It's sort of doing another compilation pass but with all of the intermediate files available, which is why the linker needs the same optimization flags as the original compile.

[KillTheMule]

As a semi-related note, in my little rust project adding lto has had a pretty serious performance impact. Benchmarks would be best, of course.

[mhinz]

@jamessan

Ah, okay. I read that gcc added a .gnu.lto section header to an ELF and hoped it (or clang) would do something similar for Mach-O.

Best answer I found: https://stackoverflow.com/questions/51048414/clang-how-to-check-if-lto-was-performed

Well, LGTM.

[justinmk]

MINGW_64 build failed. Restarted. If it fails again, @zhou13 can you try disabling LTO for mingw (by default)?

[zhou13]

MINGW_64 build seems to be OK. Failed on test.

[justinmk]

Restarted AppVeyor again. It's very unusual for the AppVeyor build to fail, so I'm hesitant to merge this until it succeeds.

Can you try disabling LTO for mingw, to see if that allows appveyor to succeed?

[ZviRackover]

Seems that Mingw32 passed while Mingw64 failed with a bunch of "plugin needed to handle lto object" errors.
FWIW, this is a similar situation to the StackOverflow question https://stackoverflow.com/questions/32221221/mingw-x64-windows-plugin-needed-to-handle-lto-object which has a solution to the issue.

[zhou13]

@ZviRackover Thanks for finding the clues!

@justinmk Should I just disable LTO for mingw, or add put the LTO plugin into the bfd-plugins directory? I don't think I can change the appveyor's CI.

[justinmk]

Should I just disable LTO for mingw,

Let's do that for now. Just add a one-line comment above the line in CMakeLists.txt, something like this:

# Disable LTO for mingw.  https://github.com/Alexpux/MINGW-packages/issues/3516

( https://github.com/Alexpux/MINGW-packages/issues/3516 has better info than the SO post. )

[zhou13]

Updated. Waiting for the CI.

[justinmk]

Thanks @zhou13 . I plan to start offering the MSVC builds in the releases instead of the mingw builds, so please report any quirks ...