xLTO: Code from standard library does not partake in linker-based LTO (unless compiling with -Clto) #64124
Labels
A-codegen
Area: Code generation
A-LLVM
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
C-feature-request
Category: A feature request, i.e: not implemented / a PR.
I-compiletime
Issue: Problems and improvements with respect to compile times.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
xLTO works by emitting LLVM bitcode instead of machine code and then letting the linker run LLVM optimizations (at a point where also code from C/C++ is available for IPO). In the current setup, this means that code from the standard library does not partake in the final LTO step because it is pre-compiled to machine code.
This limitation can be lifted by compiling to a staticlib with
-Clto
because the fat LTO step thatrustc
does pulls in the compressed bitcode version of the standard library and then emits the unified bitcode file for further processing by the linker. However, this adds an additional fat LTO step into the compilation pipeline, which is very costly.In theory it should be possible to make
rustc
emitlibstd
LLVM bitcode into the staticlib instead of the object files (if-Clinker-plugin-lto
is specified). The bitcode is available andrustc
knows how to decompress it. Then the linker could do its LTO step with the standard library included but without the additional cost.The text was updated successfully, but these errors were encountered: