> 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. > > DavidHi 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
David Chisnall via llvm-dev
2017-Jul-25 11:27 UTC
[llvm-dev] why is llvm.stacksave() necessary?
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. > > DavidThe '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