[Yul Optimizer] Extend LoadResolver to assume zeroed storage during creation code. (And zeroed memory at transaction start.)

[ekpyron]

Consider the following contract:

contract C {
        bytes x = "0123";
}

The creation code of C has to initialize the state variable x. However, in order to do so, it first reads the length field from storage, resulting in --ir-optimized --optimize of above contract to produce:

object "C_4" {
    code {
        {
            let _1 := memoryguard(0x80)
            mstore(64, _1)
            if callvalue() { revert(0, 0) }

            let _2 := 0x00
            let _3 := sload( _2) // We can assume ``sload(_2)`` to return 0!
            let length := _2
  
           ... rest of creation code....
    }

    object "C_4_deployed" {
        code {
            {
                revert(0, 0)
            }
        }
    }
}

Since at creation time, all storage slots are zero, we can resolve sload(_2) in this snippet to plain 0.

This optimization should be done in the LoadResolver optimizer step, by enriching it with the knowledge that all storage is zero at creation time. To that end, LoadResolver will need to determine whether it is run on creation code - this can for example be done by checking if it is run on a Yul object with a name that is not suffixed with _deployed.

Similarly, in a separate step, we can extend the LoadResolver to also assume that all memory is zero at the begin of each transaction. Note that this should be done separately, so there's two sub-tasks here:

• Amend the optimizer to assume zero-valued storage at the beginning of creation code.
• Amend the optimizer to assume zero-valued memory at the beginning of each transaction.

[chriseth]

It should also bring a gigantic benefit to transfer this information into functions: Whenever you call "allocate" there is an overflow check on the free memory pointer. This can be removed if all previous allocations are statically-sized (or even bounded later on).

Not all functions will be inlined into the top level, but they might be only called from the external dispatch, which could allow us to make use of this information and remove the overflow check on the free memory pointer (and even only write to it once after a series of allocations).

A complication for implementation is that the memory and storage contents works with variables and not literals values. There is a special variable for the zero value, but if we want to pull the information at the point of call into the function itself, this might be difficult because the variables are not available.