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!