IR-based Codegen error: too deep inside the stack.

[Subway2023]

Environment

• Compiler version: 0.8.27
• Target EVM version (as per compiler settings): None
• Framework/IDE (e.g. Truffle or Remix): None
• EVM execution environment / backend / blockchain client: None
• Operating system: Linux

Steps to Reproduce

pragma solidity ^0.8.0;
contract C {
    struct S { uint x; }
    uint[] storageArray;
    bytes memoryArray;
    function g(uint x) public {
        for (uint i = 0; i < x; ++i) {
            storageArray.push(i);
        }
    }
    function f(uint a) public returns (uint, uint) {
        if (a > 1) {
            g(a);
            assembly {
                let temp := sload(storageArray.slot)
                sstore(temp, msize())
            }
        }
        memoryArray = abi.encode(storageArray);
        return (storageArray.length, storageArray[0]);
    }
}

solc --via-ir --bin test.sol

Uncaught exception:
/solidity/libyul/backends/evm/EVMObjectCompiler.cpp(125): Throw in function void solidity::yul::EVMObjectCompiler::run(const solidity::yul::Object&, bool)
Dynamic exception type: boost::wrapexcept<solidity::yul::StackTooDeepError>
std::exception::what: Variable var__38 is 11 slot(s) too deep inside the stack. Stack too deep. Try compiling with `--via-ir` (cli) or the equivalent `viaIR: true` (standard JSON) while enabling the optimizer. Otherwise, try removing local variables.
[solidity::util::tag_comment*] = Variable var__38 is 11 slot(s) too deep inside the stack. Stack too deep. Try compiling with `--via-ir` (cli) or the equivalent `viaIR: true` (standard JSON) while enabling the optimizer. Otherwise, try removing local variables.

[frangio]

msize() disables the optimization pass that can fix "stack too deep".

[mehtavishwa30]

Hey @Subway2023!

Thanks for raising this issue. This case runs into a StackTooDeep error due to the use of the msize() opcode in your code. The msize() opcode makes the compiler disable the Yul optimizer. And this happens, because msize() makes our memory optimizations unsafe. What this means is that it is currently not guaranteed that the amount of memory accessed will remain the same and this fact may alter contract behaviour. However, this won't be fixed directly at the moment but the hope is that our work around improving the Yul -> EVM transformations and by the dups and swaps in EOF (EIP-663) would eliminate cases of unoptimised code leading to stack-too-deep errors, such as yours, in general.

This, IMO, serves as grounds for closing the issue for now.