Inefficient AArch64 frame generation with VLAs

[smeenai]

https://godbolt.org/z/9dj5eaxa9 shows a function with a mix of callee-saved registers, fixed size stack objects, and variable size stack objects where Clang's code generation is seemingly worse than GCC's:

• Clang requires two more callee-saved registers.
• x19 is presumably serving as the base pointer, per

  llvm-project/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp

  Lines 83 to 84 in 3ff3c4e

  	// |-----------------------------------| <- bp(not defined by ABI,
  	// |.variable-sized.local.variables....| LLVM chooses X19)

  There's no overaligned local variables here though, so I'm not sure why the base pointer is needed.
• x21 seemingly serves no purpose: the stack pointer is copied to it in line 11, and then it's copied back to the stack pointer in line 22, but the copied value is immediately overridden two instructions later (line 24), so it's never used.

Is there potential to improve the frame setup here, or am I just missing something in what Clang is doing?

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Shoaib Meenai (smeenai)

https://godbolt.org/z/9dj5eaxa9 shows a function with a mix of callee-saved registers, fixed size stack objects, and variable size stack objects where Clang's code generation is seemingly worse than GCC's: * Clang requires two more callee-saved registers. * `x19` is presumably serving as the base pointer, per https://github.com/llvm/llvm-project/blob/3ff3c4eba5d536a578abef6bf1d8520591b26dc2/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp#L83-L84 There's no overaligned local variables here though, so I'm not sure why the base pointer is needed. * `x21` seemingly serves no purpose: the stack pointer is copied to it in line 11, and then it's copied back to the stack pointer in line 22, but the copied value is immediately overridden two instructions later (line 24), so it's never used.

Is there potential to improve the frame setup here, or am I just missing something in what Clang is doing?

[efriedma-quic]

For x21, when there's a VLA, we save the stack pointer when we enter the scope, and restore it when we leave the scope. At the IR level, this is llvm.stacksave and llvm.stackrestore. We can maybe skip the restore if it's immediately before the epilogue, since the epilogue sets the stack pointer anyway.

x19 is a callee-save register to hold the address of "j", which is passed to both calls. In general, we can't use SP because there could be other allocations. In this particular case we could use SP, but it seems a little tricky to generalize.

Not sure why we're saving x20, at first glance.

[MacDue]

Not sure why we're saving x20, at first glance.

It's probably due to:

llvm-project/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp

Lines 2694 to 2700 in 40a9e34

	// Estimate if we might need to scavenge a register at some point in order
	// to materialize a stack offset. If so, either spill one additional
	// callee-saved register or reserve a special spill slot to facilitate
	// register scavenging. If we already spilled an extra callee-saved register
	// above to keep the number of spills even, we don't need to do anything else
	// here.
	if (BigStack) {

[cofibrant]

It looks like w20 is used to preserve the accumulator across the second call to f which is enough to trigger a save of x20

[smeenai]

For x21, when there's a VLA, we save the stack pointer when we enter the scope, and restore it when we leave the scope. At the IR level, this is llvm.stacksave and llvm.stackrestore. We can maybe skip the restore if it's immediately before the epilogue, since the epilogue sets the stack pointer anyway.

x19 is a callee-save register to hold the address of "j", which is passed to both calls. In general, we can't use SP because there could be other allocations. In this particular case we could use SP, but it seems a little tricky to generalize.

Not sure why we're saving x20, at first glance.

Thank you!

In theory, x19 should be unnecessary when there's only a single VLA active, since sp should always be equivalent to it, right? And x21 shouldn't be needed at the function scope (even for multiple VLAs I think), since the restore should always be right before the epilog.

Edited to add: When you have only the VLA but not the fixed size stack object (https://godbolt.org/z/ofaWeKcn3), x21 isn't used anymore, but x19 still is.

[pinskia]

We can maybe skip the restore if it's immediately before the epilogue, since the epilogue sets the stack pointer anyway.

GCC has code to specifically remove/optimize the restore in a few cases. One is before the "return". I was making changes to GCC code that does this a few months ago.

GCC optimizes it in these cases:

• a restore right before a noreturn call.
• a restore right before a return.
• a restore next to another restore; remove the first restore

Ignores simple/inexpensive builtins/intrinsics (including target builtins/intrinsics) when figuring out if the restore is next to another restore or next to the return.

[efriedma-quic]

In theory, x19 should be unnecessary when there's only a single VLA active, since sp should always be equivalent to it, right?

Essentially yes. There's potential interactions with realignment, and other stack adjustments like call frames.