Commit graph

5 commits

Author SHA1 Message Date
Vadim Petrochenkov
10d3f8a484 Move rustllvm into rustc_llvm 2020-09-09 23:05:43 +03:00
Nikita Popov
30ec68a545 Handle removal of llvm::make_unique() 2020-01-07 21:28:22 +01:00
Mark Rousskov
2a663555dd Remove licenses 2018-12-25 21:08:33 -07:00
Nikita Popov
d794597698 Remove checks for LLVM < 4.0
While we still have to support LLVM 4.0 for Emscripten, we can
drop checks for LLVM >= 4.0 and < 4.0.
2018-11-01 21:09:02 +01:00
Alex Crichton
43e8ac27d9 rustc: Persist LLVM's Linker in Fat LTO
This commit updates our Fat LTO logic to tweak our custom wrapper around LLVM's
"link modules" functionality. Previously whenever the
`LLVMRustLinkInExternalBitcode` function was called it would call LLVM's
`Linker::linkModules` wrapper. Internally this would crate an instance of a
`Linker` which internally creates an instance of an `IRMover`. Unfortunately for
us the creation of `IRMover` is somewhat O(n) with the input module. This means
that every time we linked a module it was O(n) with respect to the entire module
we had built up!

Now the modules we build up during LTO are quite large, so this quickly started
creating an O(n^2) problem for us! Discovered in #48025 it turns out this has
always been a problem and we just haven't noticed it. It became particularly
worse recently though due to most libraries having 16x more object files than
they previously did (1 -> 16).

This commit fixes this performance issue by preserving the `Linker` instance
across all links into the main LLVM module. This means we only create one
`IRMover` and allows LTO to progress much speedier.

From the `cargo-cache` project in #48025 a **full build** locally when from
5m15s to 2m24s. Looking at the timing logs each object file was linked in in
single-digit millisecond rather than hundreds, clearly being a nice improvement!

Closes #48025
2018-02-12 09:11:06 -08:00