Generate more efficient ARM64 prologs/epilogs

[filipnavara]

During the investigation of #88292 I found that NativeAOT/ARM64 and R2R never generates frameless methods. A typical app ends up with >30% of methods with simple frame prolog/epilog with no callee saved registers or extra stack space. Most of these methods are very likely to be leaf methods which can be frameless.

For example, take this simple method:

int Square(int num) { return num * num; }

NativeAOT generates the following code:

Program:Square(int):int (FullOpts):
            stp     fp, lr, [sp, #-0x10]!
            mov     fp, sp
            mul     w0, w0, w0
            ldp     fp, lr, [sp], #0x10
            ret     lr

An optimizing C compiler (clang -O) generates:

square: // @square
  mul w0, w0, w0
  ret

Not only the code size is significantly smaller, but it also saves a lot of space for the unwinding information.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

During the investigation of #88292 I found that NativeAOT/ARM64 and R2R never generates frameless methods. A typical app ends up with >30% of methods with simple frame prolog/epilog with no callee saved registers or extra stack space. Most of these methods are very likely to be leaf methods which can be frameless.

For example, take this simple method:

int Square(int num) { return num * num; }

NativeAOT generates the following code:

Program:Square(int):int (FullOpts):
            stp     fp, lr, [sp, #-0x10]!
            mov     fp, sp
            mul     w0, w0, w0
            ldp     fp, lr, [sp], #0x10
            ret     lr

An optimizing C compiler (clang -O) generates:

square: // @square
  mul w0, w0, w0
  ret

Not only the code size is significantly smaller, but it also saves a lot of space for the unwinding information.

Author:	filipnavara
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[jakobbotsch]

Dup of #35274?

[filipnavara]

An orthogonal issue would be to optionally generate prologs that are compatible with Apple Compact Unwinding:

1. The frame would need to follow a structure where x29/x30 (frame pointer, link register) are saved at the top, and the x29 registers points to the bottom of this chained structure.
2. Callee saved registers are always saved in pairs even if an odd number of them is used. At first glance this may look like a waste but it's not. The stp instruction can save two registers at a time, and the stack always has to be 16-byte aligned anyway.
3. Callee saved registers need to be saved in certain order.

An example of Apple compatible prolog is

stp x24, x23, [sp, #-0x40]!
stp x22, x21, [sp, #0x10]
stp x20, x19, [sp, #0x20]
stp x29, x30, [sp, #0x30]
add x29, sp, #0x30 ; x29/fp points just below the saved chain

The actual instructions and their order are not important, the resulting frame layout is.

Cursory observation of JIT output shows that:

1. For certain frame types the x29/x30 registers are saved at the top (correct location) but then new frame pointer (x29) is set to point to the bottom of the frame, below callee saved registers.
2. Odd number of callee saved registers results in a sequence that aligns the stack to 16-byte boundary, but it doesn't use the pattern that saves extra register.
3. The order for non-FP registers seems to be fine. FP registers and combination of FP and non-FP registers would need to be checked.

[filipnavara]

Dup of #35274?

I suppose it is a duplicate in a way, although I am specifically focusing on NativeAOT here which has slight differences in the GC suspension architecture. Also, the numbers in that issue don't correspond at all to my observations, and they don't take into account the size of unwinding information emitted in the NativeAOT case.

[EgorBo]

Inline all the small methods! 🙂

[JulieLeeMSFT]

Moving to Future because we are past .NET 8 Preview 7 code complete due date.