Turn on UnreachablePropagation by default #77680
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit a9271aa28d57e04ba28b891131eaa8cabedc16fa with merge 79c78c83b88c8bad28f42ba333ed1b59984db9af... |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit 8ca4f65 with merge 9def798b7065dbe3fba4426c64a637b6c1eeb6cd... |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
☀️ Try build successful - checks-actions, checks-azure |
|
Queued 9def798b7065dbe3fba4426c64a637b6c1eeb6cd with parent 4437b4b, future comparison URL. |
|
Finished benchmarking try commit (9def798b7065dbe3fba4426c64a637b6c1eeb6cd): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
|
It looks like this causes some minor runtime perf regressions in rustc (mir_borrowck, typeck and check_mod_privacy silghtly regressed), but does generally improve compile times. The regressions might simply be due to different inlining decisions / code partitioning, but I haven't looked into them in detail. |
|
Blessed the mir-opt tests, but now some codegen tests are failing (eg. This seems to make sense, because LLVM now has less info to work with since the |
|
cc #77800 Closing for now, until we figure out what to do with optimizations that improve compile times but regress runtime performance |
It was disabled because of pathological behaviour of LLVM in some benchmarks. As of rust-lang#77680, this has been fixed. The problem there was that it caused pessimizations in some cases. These have now been fixed as well.
UnreachableProp: Preserve unreachable branches for multiple targets
Before, UnreachablePropagation removed all unreachable branches. This was a pessimization, as it removed information about reachability that was used later in the optimization pipeline.
For example, this code
```rust
pub enum Two { A, B }
pub fn identity(x: Two) -> Two {
match x {
Two::A => Two::A,
Two::B => Two::B,
}
}
```
basically has `switchInt() -> [0: 0, 1: 1, otherwise: unreachable]` for the match. This allows it to be transformed into a simple `x`. If we remove the unreachable branch, the transformation becomes illegal.
This was the problem keeping `UnreachablePropagation` from being enabled, so we can enable it now.
Something similar already happened in rust-lang#77800, but it did not show a perf improvement there. Let's try it again anyways!
Fixes rust-lang#68105, although that issue has been fixed for a long time (see rust-lang#77680).
This was added in #66329, but turned off by default since it ran into pathological LLVM behavior leading to huge compile time regressions (#68105). Let's see if that is still the case.