This is an archive of the discontinued LLVM Phabricator instance.

[cmake] Use -ffunction-sections and -Wl,--gc-sections on MinGW targets
ClosedPublic

Authored by mstorsjo on Apr 29 2021, 1:44 PM.

Details

Summary

If compiling with GCC or linking with ld.bfd, these options have little
effect, but if built with Clang and linked with LLD, they provide a
quite notable size decrease - this shrinks an entire llvm-mingw
distribution package by 22%.

If building with BUILD_SHARED_LIBS with LLD, this requires a version
of LLD that contains a fix for auto exporting symbols from comdats,
2b01a417d7ccb001ccc1185ef5fdc967c9fac8d7.

@mati865, do you use such builds in MSYS2, and will this be an issue
for you, if you'd upgrade to LLVM 13 and build it with LLVM/LLD 12?
(Then again, you can set LLVM_NO_DEAD_STRIP on the first build to
get an initial build of LLVM 13.)

Diff Detail

Event Timeline

mstorsjo created this revision.Apr 29 2021, 1:44 PM
mstorsjo requested review of this revision.Apr 29 2021, 1:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2021, 1:44 PM
rnk accepted this revision.Apr 29 2021, 2:25 PM

lgtm

llvm/cmake/modules/HandleLLVMOptions.cmake
898–900

To the best of my knowledge, MSVC users typically get these features by default in release builds. Consider that cl /O2 enables /Gy or function sections. From there it's just a matter of passing /OPT:REF to the linker, and I think cmake does, although I don't have a minute to check right now.

This revision is now accepted and ready to land.Apr 29 2021, 2:25 PM
mati865 accepted this revision.Apr 29 2021, 4:37 PM

If compiling with GCC or linking with ld.bfd, these options have little

effect

I have observed size reduction in another project using GCC+Binutils so it's a bit surprising to me.

@mati865, do you use such builds in MSYS2, and will this be an issue

for you, if you'd upgrade to LLVM 13 and build it with LLVM/LLD 12?

We don't use BUILD_SHARED_LIBS but we do use LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB if it matters.
I don't think this will be an issue, gc-sections fix seems important enough to backport it even on its own.

I have observed size reduction in another project using GCC+Binutils so it's a bit surprising to me.

Hmm, ok, that's odd. A user tried different combinations of this in https://github.com/lovell/sharp-libvips/pull/88#issuecomment-791326495 and saw only a size increase with those options with GCC+binutils, and I tried building LLVM (statically linked only) and compared one binary where I know -ffunction-sections -Wl,--gc-sections have got a big imapct (llvm-cvtres shrinks from ~5 MB to ~500 KB). I tried GCC+LLD, GCC+binutils, Clang+binutils and Clang+LLD, and I only saw the size decrease in the Clang+LLD configuration.

We don't use BUILD_SHARED_LIBS but we do use LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB if it matters.
I don't think this will be an issue, gc-sections fix seems important enough to backport it even on its own.

Ah, right. FWIW I tested building with LLVM_LINK_LLVM_DYLIB and that configuration does break with -ffunction-sections -Wl,--gc-sections unless you have the fixed version of the linker. But you're right that the gains are big enough that it's worth working around that if needed, instead of delaying it by 1 release.

This revision was landed with ongoing or failed builds.Apr 30 2021, 12:54 AM
This revision was automatically updated to reflect the committed changes.