Document optimizer side-effect guarantees

[cameel]

Abstract

The bytecode produced by the optimizer by design does not have to preserve all the side-effects of the original. We currently do not document which effects those are specifically, which leads users to report irrelevant discrepancies as bugs. We should list them somewhere in The Optimizer docs and provide the rationale.

Here's an initial list, which may be incomplete - thinking this through is an integral part of the task:

• gas usage (optimizer assumes unlimited gas)
  • in particular, it's possible for optimization to eliminate an out-of-gas revert
• bytecode size
• number of items on stack
• warm/cold slots (SLOAD can be optimized away without warning #16445)
• memory expansion (MSIZE)
• offsets of instructions, data section, metadata, etc. within the bytecode (PC)
• presence of unused data and assemblies inside bytecode
• presence of unused data inside memory
• removal of ineffective state-modifying code (e.g. SSTORE that writes the same value, so has no effect, but would revert in a STATICCALL).

We may also want to include aspects of unspecified behavior. For example:

• Order of evaluation within a single statement
• Revert reason (e.g. failure due to not enough data returned vs explicit check that a contract does not exist)