You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MIR building for match $c { true => $i, _ => $e } is slow #60571
At the time of writing, if $c { $i } else { $e } builds MIR that is simpler and therefore is ~1-3% better in terms of compile times than match $c { $i } else { $e }. However, after the early-opt MIR optimization, they are basically the same.
In #59288 we start desugaring if expressions to match and so if we optimize for the special case of two match arms we can potentially improve compiles times.
is the entry point for if and match. we could check whether the discr is of bool type and whether both match arms are plain bool literals without a guard.
It looks like today the match-generated MIR is basically the same "complexity" at least based on a visual inspection, so I'm going to go ahead and close this -- we can circle back if there's concrete results today that show otherwise.
Activity
estebank commentedon May 10, 2019
CC #7462
Auto merge of #60730 - matthewjasper:optimize-false-edges, r=<try>
Auto merge of #60730 - matthewjasper:optimize-false-edges, r=<try>
danii commentedon Jul 9, 2021
May I volunteer in fixing? And can anyone help in pointing to the main file where match MIR is generated?
oli-obk commentedon Jul 10, 2021
rust/compiler/rustc_mir_build/src/thir/cx/expr.rs
Lines 593 to 601 in a84d1b2
c410-f3r commentedon Jan 20, 2022
let chains are now de-sugared into
ifs instead ofmatchsMark-Simulacrum commentedon Aug 23, 2022
It looks like today the match-generated MIR is basically the same "complexity" at least based on a visual inspection, so I'm going to go ahead and close this -- we can circle back if there's concrete results today that show otherwise.
For
we get: