compiler: use FramePointer::NonLeaf on illumos

[workingjubilee]

It's not clear to me if Illumos requires full frame-pointers, including leaf frames, or not. I figured I'd ask the maintainers.

r? @ghost

cc @jclulow @pfmooney

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[apiraino]

cc @jclulow @pfmooney do you have any feedback on this? thanks

[jclulow]

Hey, sorry, I have been travelling!

In general we're quite fond of having proper stack frames wherever possible. It enables us to do things like sample-based profiling and get a reasonable picture of what's going on without needing to reach all the way into the DWARF.

Do you have some more detail or specifics about what impact this would have on code generation? Is there a huge performance win? What do representative profiled stacks look like before and after, etc? Or if there's some docs I could read that would help understand the mechanism and the motivation that would be good too!

[workingjubilee]

@jclulow Hmm. My understanding of stack-based tracing is that it shouldn't have problems if the frame pointer is elided for the final function call into a leaf function. It shouldn't need a DWARF lookup. It may require more complex logic than the most naive form in order to recognize "I am in a leaf function that has elided its frame pointer", but from there it should be a simple matter to recover and get the trace. I am not familiar with the tooling on illumos, however, so I am not sure if dtrace has that amount of recovery logic.

In any case, this sort of thing has previously strongly affected inlining decisions for small-but-critical functions like mul_add.

[workingjubilee]

@jclulow More generally: I made this PR because Windows, Apple, and Linux all use this setting on aarch64 machines and still can use stack-based tracing.

[jclulow]

I have mentioned it to some colleagues, so hopefully we can study the differences more closely and come up with an answer!

[Enselic]

Triage: @jclulow Any update on this? Thanks!

[apiraino]

Sorry for yet another ping :-) is there any news here?
cc @jclulow @pfmooney

thanks

[iximeow]

I dunno if this would be great to land particularly without a motivating size/perf win. on the dtrace side, https://www.illumos.org/issues/17744 is an issue I hit a few months ago that would be applicable in all leaf functions with this, not great. mdb/pstack/etc seem like they'd be fine, but dtrace's stalk walking is a bit different for ... reasons.

fwiw I checked this with something like

fn main() {
    eprintln!("i am pid {}", std::process::id());
    leaf_caller()
}

#[inline(never)]
fn leaf_oneoff(a: u8, b: u8) -> u8 {
    a.wrapping_add(b);
}

#[inline(never)]
fn leaf_caller() -> ! {
    let mut ctr = 4;
    loop {
        ctr = std::hint::black_box(leaf_oneoff(ctr, 3));
    }
}

and this dtrace:

# dtrace -n 'profile-1003 / pid==156128 / { @[ustack()] = count(); }' -c 'sleep 1'
dtrace: description 'profile-1003 ' matched 1 probe
dtrace: pid 156132 has exited

[...snip...]

              leaftest_141798_caller`_RNvCs1TB0fkQL3ly_8leaftest11leaf_oneoff+0x3
              leaftest_141798_caller`0x46b008
              leaftest_141798_caller`_RINvNtNtCs2EQkYFqb8Mq_3std3sys9backtrace28___rust_begin_short_backtraceFEuuECs1TB0fkQL3ly_8leaftest+0x6
              leaftest_141798_caller`_RNCINvNtCs2EQkYFqb8Mq_3std2rt10lang_startuE0Cs1TB0fkQL3ly_8leaftest+0xc
              leaftest_141798_caller`_RNvNtCs2EQkYFqb8Mq_3std2rt19lang_start_internal+0x3f4
              leaftest_141798_caller`main+0x2c
              leaftest_141798_caller`_start_crt+0x87
              leaftest_141798_caller`_start+0x18
              122

[...snip...]

and any mention of leaf_caller has disappeared when you're in leaf_oneoff :( (also dtrace {u}stack() handles the no-return call into leaf_caller poorly, but that's not related to this)