I want to voice opposition against including this EIP in Glamsterdam for the same reasons that I opposed EIP-663 inclusion with EOF (cf. the Compiler Complexity Reduction section in EOF: When Complexity Outweighs Necessity - HackMD).
First of all, I want to point out that Vyper does not have the stack-too-deep problem. We have two pipelines, legacy and venom, with different tradeoffs (overuse of memory vs sometimes inefficient stack spilling), but we are making rapid progress on them. I believe Solidity is also making progress on this as well. Therefore, adding more opcodes to the VM is solving an application level problem at the VM level, needlessly increasing complexity, as enumerated below.
The solution presented by this EIP has several problems, as mentioned in the hackmd article, but I’ll enumerate them again below:
- it hurts EVM-to-native compilation (either JIT or AOT, but both have to execute within a defined performance envelope) due to the register allocation problem. Linear-time register allocation also exists, but it is suboptimal and increases memory pressure. Memory pressure should be paid for explicitly(!) by actually using EVM memory!
- it burns valuable L1 cache space – the “hot” portion of the stack grows from 512 bytes to 235 * 32 = 7.5KB, which is a substantial portion of the L1 budget (most CPUs have between 32kb and 64kb of L1 cache). allowing user-access to more stack space increases cache thrashing / stack space that is likely to be kept in cache
- the backwards-compatibility encoding to avoid JUMPDEST analysis is a complexity that clients will pay forever
It also burns opcodes needlessly, while solving the wrong problem – the reason the Solidity compiler needs deep stack access is because they can’t predict where their dynamically allocated memory will end.
EIP-7923 proposes a more general solution which solves multiple problems at once:
- heap vs call stack separation, allowing better EVM compiler design
- EVM languages can allocate reserved areas of memory for stack spilling which they can guarantee do not get trampled by other allocators
- developers get a modern memory model, not one from the 80s
- it is a general fix that improves the design space for compilers and low-level developers without adding EVM complexity besides a pricing change