rust/tests/codegen-units/partitioning/vtable-through-const.rs

95 lines
3.4 KiB
Rust
Raw Normal View History

//
// We specify incremental here because we want to test the partitioning for
// incremental compilation
// incremental
// compile-flags:-Zprint-mono-items=lazy
rustc: Don't inline in CGUs at -O0 This commit tweaks the behavior of inlining functions into multiple codegen units when rustc is compiling in debug mode. Today rustc will unconditionally treat `#[inline]` functions by translating them into all codegen units that they're needed within, marking the linkage as `internal`. This commit changes the behavior so that in debug mode (compiling at `-O0`) rustc will instead only translate `#[inline]` functions into *one* codegen unit, forcing all other codegen units to reference this one copy. The goal here is to improve debug compile times by reducing the amount of translation that happens on behalf of multiple codegen units. It was discovered in #44941 that increasing the number of codegen units had the adverse side effect of increasing the overal work done by the compiler, and the suspicion here was that the compiler was inlining, translating, and codegen'ing more functions with more codegen units (for example `String` would be basically inlined into all codegen units if used). The strategy in this commit should reduce the cost of `#[inline]` functions to being equivalent to one codegen unit, which is only translating and codegen'ing inline functions once. Collected [data] shows that this does indeed improve the situation from [before] as the overall cpu-clock time increases at a much slower rate and when pinned to one core rustc does not consume significantly more wall clock time than with one codegen unit. One caveat of this commit is that the symbol names for inlined functions that are only translated once needed some slight tweaking. These inline functions could be translated into multiple crates and we need to make sure the symbols don't collideA so the crate name/disambiguator is mixed in to the symbol name hash in these situations. [data]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334880911 [before]: https://github.com/rust-lang/rust/issues/44941#issuecomment-334583384
2017-10-06 16:59:33 -05:00
// compile-flags:-Zinline-in-all-cgus
// This test case makes sure, that references made through constants are
// recorded properly in the InliningMap.
#![feature(start)]
mod mod1 {
pub trait Trait1 {
fn do_something(&self) {}
fn do_something_else(&self) {}
}
impl Trait1 for u32 {}
pub trait Trait1Gen<T> {
fn do_something(&self, x: T) -> T;
fn do_something_else(&self, x: T) -> T;
}
impl<T> Trait1Gen<T> for u32 {
fn do_something(&self, x: T) -> T { x }
fn do_something_else(&self, x: T) -> T { x }
}
//~ MONO_ITEM fn mod1::id::<i64> @@ vtable_through_const-mod1.volatile[Internal]
fn id<T>(x: T) -> T { x }
2018-05-08 08:10:16 -05:00
// These are referenced, so they produce mono-items (see start())
pub const TRAIT1_REF: &'static Trait1 = &0u32 as &Trait1;
pub const TRAIT1_GEN_REF: &'static Trait1Gen<u8> = &0u32 as &Trait1Gen<u8>;
pub const ID_CHAR: fn(char) -> char = id::<char>;
pub trait Trait2 {
fn do_something(&self) {}
fn do_something_else(&self) {}
}
//~ MONO_ITEM fn <u32 as mod1::Trait2>::do_something @@ vtable_through_const-mod1.volatile[Internal]
//~ MONO_ITEM fn <u32 as mod1::Trait2>::do_something_else @@ vtable_through_const-mod1.volatile[Internal]
impl Trait2 for u32 {}
pub trait Trait2Gen<T> {
fn do_something(&self, x: T) -> T;
fn do_something_else(&self, x: T) -> T;
}
impl<T> Trait2Gen<T> for u32 {
fn do_something(&self, x: T) -> T { x }
fn do_something_else(&self, x: T) -> T { x }
}
2018-05-08 08:10:16 -05:00
// These are not referenced, so they do not produce mono-items
pub const TRAIT2_REF: &'static Trait2 = &0u32 as &Trait2;
pub const TRAIT2_GEN_REF: &'static Trait2Gen<u8> = &0u32 as &Trait2Gen<u8>;
pub const ID_I64: fn(i64) -> i64 = id::<i64>;
}
//~ MONO_ITEM fn start
#[start]
fn start(_: isize, _: *const *const u8) -> isize {
//~ MONO_ITEM fn std::ptr::drop_in_place::<u32> - shim(None) @@ vtable_through_const[Internal]
// Since Trait1::do_something() is instantiated via its default implementation,
// it is considered a generic and is instantiated here only because it is
// referenced in this module.
//~ MONO_ITEM fn <u32 as mod1::Trait1>::do_something_else @@ vtable_through_const-mod1.volatile[External]
// Although it is never used, Trait1::do_something_else() has to be
// instantiated locally here too, otherwise the <&u32 as &Trait1> vtable
// could not be fully constructed.
//~ MONO_ITEM fn <u32 as mod1::Trait1>::do_something @@ vtable_through_const-mod1.volatile[External]
mod1::TRAIT1_REF.do_something();
// Same as above
//~ MONO_ITEM fn <u32 as mod1::Trait1Gen<u8>>::do_something @@ vtable_through_const-mod1.volatile[External]
//~ MONO_ITEM fn <u32 as mod1::Trait1Gen<u8>>::do_something_else @@ vtable_through_const-mod1.volatile[External]
//~ MONO_ITEM fn <u32 as mod1::Trait2Gen<u8>>::do_something @@ vtable_through_const-mod1.volatile[Internal]
//~ MONO_ITEM fn <u32 as mod1::Trait2Gen<u8>>::do_something_else @@ vtable_through_const-mod1.volatile[Internal]
mod1::TRAIT1_GEN_REF.do_something(0u8);
//~ MONO_ITEM fn mod1::id::<char> @@ vtable_through_const-mod1.volatile[External]
mod1::ID_CHAR('x');
0
}