diff options
| author | bors <bors@rust-lang.org> | 2016-07-18 11:29:25 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-07-18 11:29:25 -0700 |
| commit | 9c888980763e8ba16caa67f5f08e13109bbc6fa5 (patch) | |
| tree | 4082fe088e06fca69227e0c6a526d6b5719318b4 /src/libstd/sys/unix/stack_overflow.rs | |
| parent | 06ca016b6e779ba972efb9d1735afc527d301505 (diff) | |
| parent | 22f77a917147f232d7fa96522ae539fe5b00d7f6 (diff) | |
| download | rust-9c888980763e8ba16caa67f5f08e13109bbc6fa5.tar.gz rust-9c888980763e8ba16caa67f5f08e13109bbc6fa5.zip | |
Auto merge of #34899 - michaelwoerister:always_internalize_symbols, r=eddyb
Run base::internalize_symbols() even for single-codegen-unit crates. The initial linkage-assignment (especially for closures) is a conservative one that makes some symbols more visible than they need to be. While this is not a correctness problem, it does force the LLVM inliner to be more conservative too, which results in poor performance. Once translation is based solely on MIR, it will be easier to also make the initial linkage assignment a better fitting one. Until then `internalize_symbols()` does a good job of preventing most performance regressions. This should solve the regressions reported in https://github.com/rust-lang/rust/issues/34891 and maybe also those in https://github.com/rust-lang/rust/issues/34831. As a side-effect, this will also solve most of the problematic cases described in https://github.com/rust-lang/rust/issues/34793. Not reliably so, however. For that, we still need a solution like the one implement in https://github.com/rust-lang/rust/pull/34830. cc @rust-lang/compiler
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions