There is even more than those in the language standard's introduction. In the C++ the details run on for five pages with all kinds of details. There are similar descriptions in other language standards.
The language standard is defined in the abstract. Actual compilers can make changes as needed as long as they don't change observable behavior. It is also sometimes called the "as if" rule: it can change anything it wants as long as ultimately it looks as if the C++ instructions were run exactly in the order they were given.
Many choices are left up to the actual implementation. These include sizes and alignment of things, how values are passed and processed, and how certain tasks and processing are ordered. As @Alberth describes this allows for most language optimizations and language extensions (which are permitted in C++). Processing steps can be merged, tasks can be split, and unnecessary actions can be removed entirely as long as the observable behavior is the same.
What you described, and what @Oberon_Command explained, is one of those pieces of non-observable behavior. In the C++ code you create a variable and it eventually goes out of scope. There is no observable difference to the C++ code if the space is allocated a little bit earlier. There is also no observable difference to the C++ code if the space is allocated somewhere else. While it happens to be allocated on the stack in your case, there is nothing preventing a compiler from allocating it somewhere else, like a location in scratch memory or keeping the value in CPU registers. The allocation and release could be done earlier in the program, even at program startup long before execution hits those lines. Those implementation details aren't observable to the abstract language.
In heavily optimized builds the compiler does an enormous amount of work to speed up the program, and it does all of it while preserving observable behavior. As a few examples: The compiler can move things up outside of loops; it can combine loops to run in parallel; it can combine data or split out data in certain types of processing; it can remove "dead code" it believes has no observable effects such as writing a value and then immediately overwriting the value; it can pre-compute values at compile time so they aren't computed at runtime; it can replace your math operations with different math operations that run faster on the hardware, like replacing multiplication by a constant with a shift and an addition; it can replace calls to library functions with intrinsic functions, like replacing a call to sin() with an equivalent instruction; it can inline functions so the parameters and return codes are never processed; there are