Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Absurd codegen with owned trait objects and enums #11549

Closed
alexcrichton opened this issue Jan 15, 2014 · 1 comment
Closed

Absurd codegen with owned trait objects and enums #11549

alexcrichton opened this issue Jan 15, 2014 · 1 comment
Labels
A-codegen Area: Code generation

Comments

@alexcrichton
Copy link
Member

Consider a small rust program such as this

pub trait A { fn foo(&self) {} }

#[inline(never)]
pub fn foo(slot: &mut Option<~A>) {
    slot.get_mut_ref().foo();
}

This program should essentially be a check of the discriminant followed by a vtable load + dynamic dispatch. Consider, however, the --opt-level=3 IR:

https://gist.github.com/alexcrichton/8429375

Note that I had to put that in a gist because it was too large to inline here. In summary this is generating 1500 lines of IR. This turns into kilobytes of code.

Something very odd is going on here, and this really needs to be fixed.

Nominating

@alexcrichton
Copy link
Member Author

Closing, false alarm, just turned out that begin_unwind was getting inlined all over the place (will open a PR soon).

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 15, 2014
The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in rust-lang#11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
bors added a commit that referenced this issue Jan 15, 2014
The failure functions are generic, meaning they're candidates for getting
inlined across crates. This has been happening, leading to monstrosities like
that found in #11549. I have verified that the codegen is *much* better now that
we're not inlining the failure path (the slow path).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation
Projects
None yet
Development

No branches or pull requests

1 participant