Open oli-obk opened 4 years ago
cc @rust-lang/wg-codegen @rust-lang/wg-compiler-performance this could have a not insignificant impact on compile times as a lot of panic handling code is promoted (all the datastructures for line and file information). If this could stop being evaluated for each monomorphization of generic functions that panic, this may save us quite a bit of time. I'm thinking about .unwrap()
and friends here
Interesting! Do I remember correctly that @davidtwco is working on something related for their master's thesis?
Pretty sure there is an issue about this somewhere already.
A similar but not the same bug: #46477
I believe this would be handled by a fix for #46477, which @michaelwoerister is correct that I'm working on as part of my master's thesis. There's a working group page and Zulip stream.
That's really exciting, @davidtwco! I also appreciate that you set up a proper working group for this effort.
In the following code snippet
we evaluate the
&(5 + 6)
for every monomorphization offoo
, even though we could just do this once. We should find a way to get rid of this duplicate evaluation. Maybe we can already do this at the time promoteds are created (const qualif +promote.rs
) by checkingpromoted_mir.needs_substs()
and if it's false, make thety::Const
that refers to it not have any substs itself.const_eval
will then automatically memoize all the evaluations of this promoted.Alternatively const prop could attempt to evaluate the promoted and if it fails, assume it has generics and leave it to monomorphization. This would require more CPU time than the const qualif version, since we'd do a lot of prospetive evaluations that may not succeed.