[libcxx-commits] [PATCH] D152967: [runtimes] Enable LTO when supported

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added a comment.

While enabling LTO, if possible probably is fine for the shared library, it's a much less clear cut deal for the static library.

Regarding "if possible", the CI run seems to show that it was enabled in cases where it probably didn't work in the end - e.g. the CI linux configurations, compiling with clang but linking with the system GNU linkers, probably without a suitable LLVM LTO plugin, or perhaps it's a case where it would need to use `llvm-ar` instead of GNU `ar` or something like that.

With the static library, if built with LTO, it pushes the compilation of the library onto every single user who links an executable. If linking a single executable that's probably fine, but for a generic toolchain that can be used in a multitude of ways, it's probably a different tradeoff. If linking e.g. hundreds of small executables against a static libc++ (for users who don't enable LTO otherwise), you'd now end up compiling the libc++ code hundreds of times, with no actual benefit if the rest of the executables linked isn't built with LTO.

I believe this issue should show up in CI too, for the static-only configurations, where the runtime of the testsuite that builds thousands of test executables probably would skyrocket. (The current CI run seems to have failed earlier than that, so I couldn't check how it actually went this time.)

So IMO, whether to enable LTO for the static library build or not should probably be a build time option, for toolchain vendors to decide upon.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D152967/new/

https://reviews.llvm.org/D152967