Don't save/restore the stack if it's unused in the current function

[bnjbvr]

• What is the feature or code improvement you would like to do in Cranelift? Small functions which don't make usage of the stack will still preserve the stack pointer by saving it into the frame pointer register, which is spurious. It's a few instructions per call which could be removed in general.
• What is the value of adding this in Cranelift? Runtime speedup.
• Do you have an implementation plan, and/or ideas for data structures or
  algorithms to use? Have you considered alternative implementations? If so, how are they better
  or worse than your proposal? Implementation should be trivial: lookup the number of stack slots
  and don't preserve SP if there are no stack slots.

[bjorn3]

I think we should also do this if the stack usage is less than the red zone and it is a leaf function. We need to be aware that running legalization on calls can introduce new stack slots though.

[bnjbvr]

I think we should also do this if the stack usage is less than the red zone and it is a leaf function.

Are you talking about something different here, like choosing to emit or not an overflow stack check?

We need to be aware that running legalization on calls can introduce new stack slots though.

Generating the prologue and epilogue happens after register allocation (because we need to know about spill slots), so function call legalization has run a long time ago. Is there something I'm missing here?

[bjorn3]

Are you talking about something different here, like choosing to emit or not an overflow stack check?

No, when the stack usage is less than the red zone and it is a leaf function, then it is possible to avoid changing the stack pointer, thus omitting the epilogue and prologue.

Generating the prologue and epilogue happens after register allocation (because we need to know about spill slots), so function call legalization has run a long time ago. Is there something I'm missing here?

I thought it happened during legalization, but I guess that is not the case.

[bnjbvr]

By "red zone", do you mean the stack guard page? if so, is LLVM doing such a thing?

[bjorn3]

https://en.m.wikipedia.org/wiki/Red_zone_(computing)

In computing, a red zone is a fixed-size area in a function's stack frame beyond the current stack pointer which is not preserved by that function. The callee function may use the red zone for storing local variables without the extra overhead of modifying the stack pointer. This region of memory is not to be modified by interrupt/exception/signal handlers. The x86-64 ABI used by System V mandates a 128-byte red zone,[1][2] which begins directly under the current value of the stack pointer.

[bnjbvr]

Ok, so it's really only for SysV x86 64-bits; Win64's fastcall does something different. I see that LLVM does this for leaf functions, using negative offsets based off $rsp. Thanks for bringing this up.

[projjal]

Hi. I'd be interested in working on this if it is available.

[projjal]

From what I understood, here [1] if the size of pos.func.stack_slots is zero and it is a leaf function we would skip pushing the fp to stack and copying the sp to fp. Is it correct?

[1] : https://github.com/bytecodealliance/cranelift/blob/bed9a72a777f1b972e58ad250ead851585d9ab1e/cranelift-codegen/src/isa/x86/abi.rs#L618

[bjorn3]

Does this regress backtraces from a debugger? If so, can this be placed behind a setting? (omit_stack_frame=yes/no/auto, auto means only for opt-level=speed/speed_and_size)

[projjal]

Does this regress backtraces from a debugger? If so, can this be placed behind a setting? (omit_stack_frame=yes/no/auto, auto means only for opt-level=speed/speed_and_size)

So it seems debuggers use frame pointer to backtrace the stack frames which won't work with this approach. Using a flag for adjusting the behavior makes sense. Thank you.

[iximeow]

@bjorn3 I don't think this would interact with backtraces if .eh_frame is generated, on Linux. Not as sure about Windows or MacOS, but if the stack is totally unused we'll just conditionally have significantly less in .eh_frame for these functions.

If you mean right now, without .eh_frame, I'm much less confident, but hopefully we can start landing that stuff soon.

[peterhuene]

On Windows x64, you don't need a frame pointer to walk the stack or unwind unless there's a special need to (e.g. dynamically sized stack allocations are one reason). Even if you do use a frame pointer, the unwind information must be present to let Windows know if there's a frame pointer, which register it is, and at which offset in the prologue the frame is established. It would be nice for the Windows x64 calling convention if Cranelift did omit the frame pointer in at least optimized compilations.

[projjal]

Hi I got a bit confused here [1]. Shouldn't it be just self.dfg.signatures.is_empty() (no negation). Similarly must_align = !is_leaf here[2]. Or am I missing something?
cc @bnjbvr
[1]
https://github.com/bytecodealliance/cranelift/blob/0b40b114f66702478148f1184c768307b9599870/cranelift-codegen/src/ir/function.rs#L298
[2]
https://github.com/bytecodealliance/cranelift/blob/0b40b114f66702478148f1184c768307b9599870/cranelift-codegen/src/stack_layout.rs#L49

[bnjbvr]

Good catch. It only works because the second mistake fixes up the first one...