Minor correction though, I think this is not quite correct:
> The compiler computes the required size at compile time by summing the sizes of all locals (accounting for alignment).
In optimized C++ builds, compilers can reuse stack storage for locals whose live ranges don’t overlap, so the required stack frame size is not necessarily the sum of all locals. Some locals may never have stack storage at all (e.g. living entirely in registers or being optimized away).
For objects with non-trivial destructors, storage reuse is constrained by object lifetime and destruction semantics, but the same stack slot may still be reused after the destructor has run.
Minor correction though, I think this is not quite correct:
> The compiler computes the required size at compile time by summing the sizes of all locals (accounting for alignment).
In optimized C++ builds, compilers can reuse stack storage for locals whose live ranges don’t overlap, so the required stack frame size is not necessarily the sum of all locals. Some locals may never have stack storage at all (e.g. living entirely in registers or being optimized away).
For objects with non-trivial destructors, storage reuse is constrained by object lifetime and destruction semantics, but the same stack slot may still be reused after the destructor has run.