Repository navigation
Copy trait defeats generator optimization #62952
Description
The following example (playground):
#![feature(generators, generator_trait)]
use std::ops::Generator;
#[derive(Clone)]
struct Foo([u8; 1024]);
fn overlap_foo() -> impl Generator<Yield = (), Return = ()>{
static || {
let x = Foo([0u8; 1024]);
yield;
drop(x);
let y = Foo([0u8; 1024]);
yield;
drop(y);
}
}
#[derive(Clone, Copy)]
struct Bar([u8; 1024]);
fn overlap_bar() -> impl Generator<Yield = (), Return = ()>{
static || {
let x = Bar([0u8; 1024]);
yield;
drop(x);
let y = Bar([0u8; 1024]);
yield;
drop(y);
}
}
fn main() {
dbg!(std::mem::size_of_val(&overlap_foo()));
dbg!(std::mem::size_of_val(&overlap_bar()));
}Outputs:
[gen-explicit-drop.rs:34] std::mem::size_of_val(&overlap_foo()) = 1028
[gen-explicit-drop.rs:35] std::mem::size_of_val(&overlap_bar()) = 2052
The only difference between Foo and Bar is that Foo is Copy. This defeats the generator optimization implemented in #61922 which considers any local that has been moved from as a candidate for overlap.
Technically, this is semantically consistent with the existing overlap behavior for generators. But making a type Copy and getting worse performance is a footgun that we should fix.
This can be fixed with a pass that turns unnecessary copies into moves in MIR.
Activity
Centril commentedon Jul 25, 2019
I thought that's what https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/copy_prop/index.html does?
cc @oli-obk
tmandry commentedon Jul 30, 2019
Nice find, this does indeed do the required transformation. Running that
(along with simplify_locals)right before the generator transform almost does the trick.The problem is that we currently eliminate all storage markers as part of copy_prop, and this defeats the generator optimization. If we merged the live ranges of the two variables instead, it should work.
(EDIT: simplify_locals is not needed)