Skip to content

Commit 86c60b6

Browse files
committedJan 15, 2014
Flag failure functions as inline(never)
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).
1 parent dd8b011 commit 86c60b6

File tree

1 file changed

+2
-0
lines changed

1 file changed

+2
-0
lines changed
 

Diff for: ‎src/libstd/rt/unwind.rs

+2
Original file line numberDiff line numberDiff line change
@@ -364,6 +364,7 @@ pub mod eabi {
364364
/// This is the entry point of unwinding for things like lang items and such.
365365
/// The arguments are normally generated by the compiler, and need to
366366
/// have static lifetimes.
367+
#[inline(never)] #[cold] // this is the slow path, please never inline this
367368
pub fn begin_unwind_raw(msg: *c_char, file: *c_char, line: size_t) -> ! {
368369
#[inline]
369370
fn static_char_ptr(p: *c_char) -> &'static str {
@@ -381,6 +382,7 @@ pub fn begin_unwind_raw(msg: *c_char, file: *c_char, line: size_t) -> ! {
381382
}
382383

383384
/// This is the entry point of unwinding for fail!() and assert!().
385+
#[inline(never)] #[cold] // this is the slow path, please never inline this
384386
pub fn begin_unwind<M: Any + Send>(msg: M, file: &'static str, line: uint) -> ! {
385387
// Note that this should be the only allocation performed in this block.
386388
// Currently this means that fail!() on OOM will invoke this code path,

0 commit comments

Comments
 (0)