]> git.lizzy.rs Git - rust.git/commit - src/tools/miri
Auto merge of #82127 - tgnottingham:tune-ahead-of-time-codegen, r=varkor
authorbors <bors@rust-lang.org>
Tue, 23 Feb 2021 14:38:45 +0000 (14:38 +0000)
committerbors <bors@rust-lang.org>
Tue, 23 Feb 2021 14:38:45 +0000 (14:38 +0000)
commit019610754363d1d92a8d0f364d2c0909d6f53dfd
tree618b31afa4f153f3af52d6246b2e24ae0fac2b47
parent446d4533e89db04f9568be4199e56b5fce0d176d
parent5f243d3c2bf4188ec782e43b695e50602c777cd9
Auto merge of #82127 - tgnottingham:tune-ahead-of-time-codegen, r=varkor

rustc_codegen_ssa: tune codegen according to available concurrency

This change tunes ahead-of-time codegening according to the amount of
concurrency available, rather than according to the number of CPUs on
the system. This can lower memory usage by reducing the number of
compiled LLVM modules in memory at once, particularly across several
rustc instances.

Previously, each rustc instance would assume that it should codegen
ahead of time to meet the demand of number-of-CPUs workers. But often, a
rustc instance doesn't have nearly that much concurrency available to
it, because the concurrency availability is split, via the jobserver,
across all active rustc instances spawned by the driving cargo process,
and is further limited by the `-j` flag argument. Therefore, each rustc
might have had several times the number of LLVM modules in memory than
it really needed to meet demand. If the modules were large, the effect
on memory usage would be noticeable.

With this change, the required amount of ahead-of-time codegen scales up
with the actual number of workers running within a rustc instance. Note
that the number of workers running can be less than the actual
concurrency available to a rustc instance. However, if more concurrency
is actually available, workers are spun up quickly as job tokens are
acquired, and the ahead-of-time codegen scales up quickly as well.
Cargo.lock
compiler/rustc_codegen_ssa/src/back/write.rs