llvm dev - Jul 2017 - why is llvm.stacksave() necessary?

> Clang does this because clang intentionally generates IR naïvely and relies
on LLVM optimisation passes to clean it up.
> 
> In the case of C VLAs, the size of the alloca changes whenever the
declaration goes into scope.  By emitting a stack save and restore for d, clang
doesn’t need to have different IR generating code for your example and for this
one:
> 
> void myfunc(void
> {
> 	for (int i=0 ; i<4; i++)
> 	{
> 		double d[i];
> 		doSomethingWith(d);
> 	}
> }
> 
> In this case, each time that the loop is entered you will get a new d with
a different size.  Clang emits code that handles this case, and an early
optimisation pass will remove the stack save and stack restore intrinsics if
they’re not actually needed.
> 
> David
Hi David,
good example, thank you.
This means than, when generating VLA's, one would need to check for the
'minimal' part which needs to be enclosed by safe/remove (in this
example the related calls need to enclose the inner part of the loop).

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?

Thx
Alex

On 25 Jul 2017, at 12:17, alex via llvm-dev <llvm-dev at lists.llvm.org>
wrote:
> Hi David,
> good example, thank you.
> This means than, when generating VLA's, one would need to check for the
> 'minimal' part which needs to be enclosed by safe/remove (in this
> example the related calls need to enclose the inner part of the loop).
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

> 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?
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...

Alex