Skip to content

Conversation

@alexrp
Copy link
Member

@alexrp alexrp commented Dec 14, 2024

No description provided.

@alexrp alexrp force-pushed the lto-stuff branch 3 times, most recently from 70233bb to c8bf08c Compare December 14, 2024 13:15
@alexrp alexrp force-pushed the lto-stuff branch 2 times, most recently from ea1fb87 to 34c3466 Compare December 16, 2024 05:11
@alexrp alexrp changed the title Disable LTO by default + some fixes for LTO on Windows Disable LTO by default + some LTO fixes Dec 16, 2024
@linusg
Copy link
Collaborator

linusg commented Dec 16, 2024

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)?

@andrewrk
Copy link
Member

andrewrk commented Dec 16, 2024

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 .bc file, and likewise you configure your other objects to emit LLVM bitcode files, and then finally you perform the link with Clang/LLD. In such a use case Zig is participating in a larger strategy here and can't really be the "boss" that links everything together. Its role is only to produce LLVM bitcode for the Zig source code component.

alexrp added 10 commits January 25, 2025 13:49
libc provides these when targeting MSVC.
…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.
Copy link
Member

@andrewrk andrewrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks! I feel a lot better about disabling LTO for compiler_rt and mingw than adding all those -u things.

@andrewrk andrewrk merged commit 8fa47bb into ziglang:master Jan 25, 2025
10 checks passed
@alexrp alexrp deleted the lto-stuff branch January 27, 2025 08:21
alexrp added a commit to vezel-dev/zig-sdk that referenced this pull request Mar 5, 2025
It's too buggy and Zig will soon remove support for it anyway.

See: ziglang/zig#22230
alexrp added a commit to vezel-dev/zig-sdk that referenced this pull request May 24, 2025
It's too buggy and Zig will soon remove support for it anyway.

See: ziglang/zig#22230
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants