Disable LTO by default + some LTO fixes#22230
Conversation
alexrp
changed the title
|
I never did a comparison of LTO enabled vs disabled for any of my Zig projects, what are the expected performance or size saving losses from turning this off by default (and dropping it entirely down the line)? |
|
Mainly it lets functions become inlined (and then further optimized) between compilation units. So if you have a hot loop that involves different objects calling into each other, it could make a big difference. However if your hot loops are all part of the same object files then it won't make a difference, really. Also to be clear, what will be dropped entirely is using Zig as the linker for the LTO use case. That doesn't really work since LTO includes a dependency on Clang, GCC, or another third party, and making sure all objects that participate emit IR instead of machine code. So how this would work in the future for Zig is that you would have a build configuration option that chooses the LLVM backend, Zig outputs a |
libc provides these when targeting MSVC.
Necessary because of: llvm/llvm-project@dc665fa
…ing to LLVM. See 652c515. Better to avoid relying on default LLVM behavior going forward.
If this isn't done, LTO can completely miscompile the input bitcode modules for certain targets where we need to explicitly set these ABIs (because LLVM's defaults are bad).
* compiler-rt and mingw32 have both run into LLD bugs, and LLVM disables LTO for its compiler-rt, so disable LTO for these. * While we haven't run into any bugs in it, LLVM disables LTO for its libtsan, so follow suit just to be safe. * Allow LTO for libfuzzer as LLVM does.
No longer needed since we disable LTO for mingw32.
LLD has too many LTO bugs, and we're dropping the LLD dependency soon anyway.
andrewrk
left a comment
andrewrk
left a comment
There was a problem hiding this comment.
Looks great, thanks! I feel a lot better about disabling LTO for compiler_rt and mingw than adding all those -u things.
It's too buggy and Zig will soon remove support for it anyway. See: ziglang/zig#22230
It's too buggy and Zig will soon remove support for it anyway. See: ziglang/zig#22230
4 participants
No description provided.