better heuristics for choosing variables to move to memory

[sifislag]

Description

I've been looking at bytecodes produced using the --via-ir pipeline and I noticed that in most cases, popular constants (0, 4, etc.) are pushed to the stack on the function selector code and shared between public functions. I stumbled upon a contract where the memory mover kicks in to resolve stack too deep errors. This behavior can be seen in the produced yul code, with 0 being stored at memory offset 0xa0. After this point the constant is loaded 271 times (can be observed by searching "60a051" in the deployed bytecode).

So in this case the sequence 60a051 is used instead of 6000, adding 271 extra bytes to the deployed bytecode. Thought to report it as it will probably be common in large programs.

Environment

• Compiler version: 0.8.17 (also on 0.8.19)
• Target EVM version (as per compiler settings): london
• Operating system: ubuntu 20.04

Steps to Reproduce

I got the contract's code concatenated to a single file from here and compiled using 0.8.19 (after removing imports, etc). The same behavior is present. I'm not posting it here because its too large.

[ekpyron]

Yeah, there's two underlying issues involved in this - for once the memory-mover currently naively chooses the first candidate for moving to memory to solve stack-too-deep errors rather than analyzing the cost for all candidates and choosing the cheapest one based on some heuristics. Secondly, the code transform (i.e. the transformation from yul code to evm bytecode) does currently not always make use of the fact that it knows the value of constants and can replace variable references by constants.

Both of this are known problems and it's on our agenda to improve both of the components involved.
I'll be linking this issue to #13721, which will involve improving the mentioned code transform to account for the example case you're posting - thank you very much for that, concrete examples help a lot in tweaking these mechanisms!

Beyond that I'll leave this issue open, but will repurpose it to a more general improvment of the heuristics of moving variables to memory, which is the second component involved in this.

[sifislag]

Thanks for the explanation!
I can get you more examples if that'd be helpful. I ran a quick analysis on ~900 contracts compiled using --via-ir, in 42 of them the memory mover was used (according to my heuristic) and I found 20 instances where small (single byte) constants are stored on an offset reserved by the memory mover.