[Codegen] Recursive fallback function call runs out of gas via legacy but does not via IR

[bshastry]

contract C0 {
  fallback() external virtual
  {
    assembly
    {
      calldatacopy(0, not(0), 96)
    }
    (bool l0, bytes memory l1) = address(this).call(bytes("ffffffffffffffffffffffffffffffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000"));
  }
}
// ====
// compileViaYul: also
// ----
// () -> FAILURE
// gas irOptimized: 211360

Legacy: FAILURE
IR: Pass

[ekpyron]

I'm labeling this codegen error, to heighten the priority of properly investigating this, even though I still hope, it's mostly a testing issue.

[ekpyron]

I think this may be spurious after all - and just a crazy thing happening here :-).
I've not confirmed entirely yet, but I think
calldatacopy(0, not(0), 96) can be replaced with anything that ends up having the same gas cost.

What I guess will happen is that the last recursive call to this may just report failure, but the contract may still have enough gas to finish returning, depending on legacy vs via-IR. But we have to confirm that everything is sane there wrt. gas forwarding, etc.
It's surprising in any case :-).

[ekpyron]

Or to be even clearer: the maximum forwarded gas is 63/64 of the available gas.
So if the recursive call runs out of gas, we still have 1/64 of the total gas left. This may just be enough for finishing the transaction in via-IR codegen, while it may not be with legacy codegen.

[ekpyron]

Several of the recursive calls may manage to return with the available gas - when I added some event to the code example (which of course skews gas costs, so it won't be exactly the same), I saw somewhere between 100 and 200 calls succeeding.

[bshastry]

@ekpyron Isn't calldatacopy(0, not(0), 96) in this issue's test case also overwriting the free memory pointer. If so, could this also be undefined behavior between legacy and IR?

[ekpyron]

That's true... although my guess would be that one could construct similar cases without that... on the other hand, trying that, it's not that easy :-). Overwriting the free memory pointer there, may mainly result in weird data to be passed during the recursive call, though.