It is not really true and it serves no purpose here.

This is the old offset allocation scheme that we were using originally, before the var offset allocator was added. Vars have the same offset as they would have in IL code, based on their position on the execution stack at the moment when they are pushed. Whenever we push/pop on the execution stack we keep track of the used stack size. Every var pushed on the execution stack will therefore have this stack_offset remembered. Once the entire IL code is traversed and we have all the global locals allocated, the real offset of the execution stack locals can be determined. It is computed as the originally determined stack_offset added with the offset of the execution stack start (size of the global locals space).

With this offset allocator, calls no longer need to store all the call args sregs and the return_offset is always the same as call_args_offset. This is because all vars are directly placed in the right position and no optimizations can move them around. The offset of the return value will therefore be also the offset where all the args are placed.

The limitation with this way of allocating offsets is that we run into the same problems with opcodes that don't have typical stack usage (use values, pop them, store result). This happens with newobj opcodes. The opcode receives the params, and then it needs to call a ctor with these same params and a newly allocated this object. Since we can't use a var offset allocation pass to compute the offset ideally, the newobj opcodes in the case of unoptimized code must move these params around on the stack, in order to make room for `this`.