Rust: Don't evaluate promoteds for each monomorphization if it does not depend on generic parameters

Created on 9 Dec 2019  路  6Comments  路  Source: rust-lang/rust

In the following code snippet

fn foo<T>() -> &'static i32 {
    &(5 + 6)
}

we evaluate the &(5 + 6) for every monomorphization of foo, 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 checking promoted_mir.needs_substs() and if it's false, make the ty::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.

A-const-eval C-enhancement I-compiletime T-compiler

Most helpful comment

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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings