[llvm-dev] why is llvm.stacksave() necessary?

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 25 08:46:46 PDT 2017

On 25 Jul 2017, at 16:40, alex via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> In C, the ‘minimal’ part is called the ‘scope’.  Variables are always destroyed in the inverse order to the order in which they are created and so it’s always trivial to translate each into a stack save followed by an alloca when the variable comes into scope and a stack restore when the variable goes out of scope.
>>> what would happen if stack safe/remove would be neglected?
>>> at the end of the function everything should get cleaned-up - right?;
>>> the only problem could be that one consumes much more stack than
>>> necessary - not?
>> Exactly.  Each alloca would allocate more memory.  gcc used to have a bug that did this, which bit me in the past (about 15 years ago), where using a VLA in the form from my example would consume stack space in proportion to the sum of all values of i, rather than in proportion to the maximum value of i.  
>> David
> The 'scope'in should be related to the block in IR - not?

No.  LLVM IR has no notion of nested scopes (global and function are the only two scopes that exist), only of liveness.  A value is considered live.

> This would then be easy: just insert a stackSafe right infront of the
> alloca (as you suggested) and a restore at the end of the block…

Unless your source language permits flow control, in which case you must insert the stack restore in the block that unifies flow control at the end of the scope.  Consider this example:

void myfunc(void)
	for (int i=0 ; i<4; i++)
		double d[i];
		if (i % 2)

The IR that clang generates for this is quite hard to read, but the key point is that the stack save and stack restore are in different basic blocks.  


More information about the llvm-dev mailing list