diff options
| author | bors <bors@rust-lang.org> | 2023-06-16 18:21:22 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-06-16 18:21:22 +0000 |
| commit | 6bba061467f7c2cab04b262b95eb67bf89265587 (patch) | |
| tree | fe1733365c4cbf05ff9ce5e6c2e604100887f884 /compiler/rustc_mir_transform/src/coverage/debug.rs | |
| parent | 6a94e87a54ecf2df307c65af2dbc2effb3a525b8 (diff) | |
| parent | c153f3a356b0e7917c91d3a804b93fadffb778b0 (diff) | |
| download | rust-6bba061467f7c2cab04b262b95eb67bf89265587.tar.gz rust-6bba061467f7c2cab04b262b95eb67bf89265587.zip | |
Auto merge of #112294 - saethlin:inline-me-maybe, r=oli-obk
Ignore the always part of #[inline(always)] in MIR inlining `#[inline(always)]` is used in two cases: for functions that are so trivial it is always profitable to inline them, but also for functions which LLVM thinks are a bad inlining candidate, but which actually turn out to be profitable to inline. That second justification doesn't apply to the MIR inliner, so ignoring our cost estimation for these functions is not necessarily the right right thing to do. This is basically a wash on non-check runs and a perf benefit in check runs. There are some notable regressions, and I think we might be able to claw those back by turning `#[inline(always)]` into a stronger hint. But I think this PR stands decently on its own as a tidy simplification.
Diffstat (limited to 'compiler/rustc_mir_transform/src/coverage/debug.rs')
0 files changed, 0 insertions, 0 deletions