I've never seen a compiler that didn't allocate the entire stack space at the start of the function. This makes sense in almost every case. A simple sub esp,size is all that is needed.
I really cannot think of many situations where this approach would not be optimal.
Code:
push ebp
mov ebp,esp
sub esp,needed_stack_space
It does not make sense to incrementally subtract various variable sizes from esp as the compiler encounters local variable declarations. It makes more sense for the compiler to first compute how much size is needed to accomodate all local variables and then allocate that in one operation as opposed to many. It also makes no sense for the compiler to delay the allocation of a stack variable until it reaches it as in the case of a loop.
Code:
for (unsigned int i = 0;i < 10; ++i)
{
unsigned int total = 0;
total = i * 5 + i;
}
In this case it has been my experience that total would be allocated long before the loop was ever reached in the code. Also if you notice the creation of total is essentially non-variant code that is inside of a loop and even the dumbest of compilers would optimize this out of the loop.
Also you can see that the i variable used to loop is obviously not being allocated every time through the loop which according to the late de-allocation crowd would happen. Clearly this is not happening.
I would say that the compiler in this case would do this:
Code:
push ebp
mov ebp,esp
sub esp,8
...
However if the compiler chose to use ECX for i and do a simple LOOP operation then the stack size would change to 4 bytes. Depending on the calling convention of the function you may or may not see the stack cleaned up.