Use side effects of user-defined functions in other optimizer steps.

[chriseth]

No description provided.

[chriseth]

I think it might really make sense to cache the side-effects in the context (same is true for the other side-effects as well).
If optimizer steps are semantically-equivalent transformations, then it should be OK to compute the side-effects once per optimizer loop iteration.

[chriseth]

Performance does not seem to be as big an issue as I thought.

[bshastry]

Fuzzer update:

There is a stack-use-after-scope here:

solidity/libyul/ControlFlowSideEffectsCollector.cpp

Line 215 in 863a0d3

for (YulString callee: util::valueOrDefault(m_functionCalls, _function))

(see #10973 (comment) for discussion on a similar issue)

I am not sure if YulString as an rvalue reference temporary is the issue. At least one of similar issues in the past could be fixed by replacing temporary with a value on the stack. (see #11371)

[chriseth]

Before merging this, some tests may need to be modified so that they are still purposeful.

[chriseth]

Changed the tests to be meaningful, please double-check.

[chriseth]

I think this could need some more tests in the relevant optimizer steps.

[ekpyron]

Not that we need it right away, but in general it makes sense to distinguish between terminating and reverting here, doesn't it?

function f() { return(0,0) }
function g() { revert(0,0) }
{
  switch calldataload(0)
  case 0 {
    sstore(0, 0) // needs to stay
    f()
  }
  case 1 {
    sstore(0, 0) // can be removed
    g()
  }
}

[ekpyron]

Assuming that the side effects are correct :-), this looks good!

I'm wondering if it's worth to catch this eventually:

for {} 1 {} {
  if g() { return(...) }
}
sstore(0, 1) // can be removed

but no need now in any case.