Stack alignment in leaf functions

Project Infrastructure LLVM Dev List Archives
1

Hi,
right at the moment, LLVM won't align the stack for leaf functions. So, if
stack alignment is 8 bytes, and leaf function has 1 variable of 4 bytes,
the size of frame will be computed as 4 bytes, making stack pointer inside
function non-aligned.

I've mentioned this before:

   http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-March/003701.html

but did not pursue the issue back then.

For my target, the stack should be aligned even for leaf functions. In
particular, hardware interrupt can arrive at any time, and stack should be
8-byte aligned at the time of interrupt, otherwise things will break.

I can address this issue by using two tricks together:

1. Calling MachineFrameInfo::setHasCalls in my backend
2. Using the attached patch, so that value of setHasCalls is not reset to
false later.

Comments?

BTW, I've checked other uses of MachineFrameInfo::hasCalls. For example,
PPCRegisterInfo uses it to check if if callee save registers can be stored
in something called "red zone", whatever that is.

I wonder how this relates to interrupts. Say, function X is running.
Interrupt arrives, and the interrupt handlers calls function X again. So, if
that "red zone" is some static memory area, the values there are
overwritten. Am I missing something? Should there be some "interrupts safe"
mode?

- Volodya

PrologEpilogInserter.diff (832 Bytes)

2

right at the moment, LLVM won't align the stack for leaf functions. So, if
stack alignment is 8 bytes, and leaf function has 1 variable of 4 bytes,
the size of frame will be computed as 4 bytes, making stack pointer inside
function non-aligned.

Ok.

I've mentioned this before:
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-March/003701.html
but did not pursue the issue back then.

For my target, the stack should be aligned even for leaf functions. In
particular, hardware interrupt can arrive at any time, and stack should be
8-byte aligned at the time of interrupt, otherwise things will break.

Gotcha.

I can address this issue by using two tricks together:

1. Calling MachineFrameInfo::setHasCalls in my backend
2. Using the attached patch, so that value of setHasCalls is not reset to
false later.
Comments?

Unfortunately, I don't *think* this is the right approach. I really think that HasCalls should be an accurate indication of whether or not there are calls, it shouldn't be overloaded if possible.

I *think* that this should be an issue that you can handle completely in your target code. In particular, the stack size set in the FrameInfo is just a required minimum stack size. In your <Target>RegisterInfo.cpp file, you can use this size as a starting point, then adjust it as you see fit. In the X86 backend, for example, it does do explicit realignment of the size in certain cases, I think you should be able to do it as well.

BTW, I've checked other uses of MachineFrameInfo::hasCalls. For example,
PPCRegisterInfo uses it to check if if callee save registers can be stored
in something called "red zone", whatever that is.

Right. In the case of PPC/X86-64, a red zone is a small region that you are allowed to to offset below the stack pointer. Signals are delivered at some offset below it.

I wonder how this relates to interrupts. Say, function X is running.
Interrupt arrives, and the interrupt handlers calls function X again. So, if
that "red zone" is some static memory area, the values there are
overwritten. Am I missing something? Should there be some "interrupts safe"
mode?

For ABIs with red zones, the signal is delivered some offset below the stack pointer, making it okay to use it.

-Chris