Modifiers add to stack, discourages modifier usage

[redsquirrel]

I assume there's nothing that can be done about this, but I was surprised to see that the following contract doesn't compile because each modifier is added to the stack:

pragma solidity ^0.4.17;

contract Testing {
    modifier a(uint256 x) {
        require(true);
        _;
    }

    function foo(uint256 x)
        public
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
        a(x)
    {
        uint256 aa = 22 + x;
    }
}

Error:

browser/Testing.sol:27:27: CompilerError: Stack too deep, try removing local variables.
        uint256 aa = 22 + x;
                          ^

For methods with many modifiers and a lot of variables, it means that people will need to write functions to do their checking instead of modifiers in order to work around stack depth issues. Like this:

pragma solidity ^0.4.17;

contract Testing {
    function a(uint256 x) {
        require(true);
    }

    function foo(uint256 x) public {
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        a(x);
        uint256 aa = 22 + x;
    }
}

Is this expected behavior?

[federicobond]

Yes, that is expected behavior. Since modifier wraps the function like a decorator, the variable x which is pushed into the stack at the beginning of the call to foo must remain available until the _; returns.

You showcase an interesting case though, and I think there is a simple optimization to be made here, which is to pop modifier local variables when the _ statement is in tail position.

[federicobond]

There is a more general case to be made for incorporating liveness analysis into the compiler, as long as it can intelligently balance stack/gas tradeoffs.

[chriseth]

We are not planning any such optimizations at the high level language layer, since the benefit / danger - ratio is just too low.

[axic]

I think it is good to keep this open as a reminder. With the new IR it should be possible to move some of the arguments into memory to accommodate this (or evm1.5/ewasm would actually allow way more arguments).

[axic]

@leonardoalt @chriseth @ekpyron I think with the new scoping rules this could be improved in certain cases.

[chriseth]

Not really, because modifiers generate a block that surrounds the function.

[hshar7]

My code is now a lot uglier because of this

[wminshew]

I know this is low priority but feel like it should be re-considered. At least in the case where _; comes at the tail-end..

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.