Reduce Evm Stackspace clearing

[benaadams]

As there are a large number of CALL/DELEGATECALL/STATICCALL per transaction and each call becomes both a call and call back the ExecuteCall/Code method is executed many times. On currently on entering the method it zeros 9136 bytes of stack.

Some blocks can make up to 4k+ calls meaning 8k+ method entries for these heavy blocks or 70MB. Also the method is 26.5kb of asm which reduces the Jits willingness to optimize and is a large code chunk for a hot loop.

e.g. in the example below 7 blocks execute 724 txs which calls ExecuteCall 10.5k times meaning 92MB of stack needs to be cleared

This change reduces to to 1328 bytes of stack or 78MB less in the example above; and reduced the hot loop from 26.5kB to 17.2kB so is more likely to be hotter in the CPU L1 execution cache (32KB - 48KB)

Changes

• Split ExecuteCall-> ExecuteCall+ExecuteCode; the first being setup and second being hot loop to reduce register pressure on the loop from the setup.
• Reuse large struct stack variables; as the Jit will allocate a spot in the stack for each declaration
• Reduce method code/repeats for failures
• Move Sstore to own method, uses a fair amount of stack variables and not commonly called as %
• Move Log to own method, uses a fair amount of stack variables and not commonly called as %
• Move create to own method, uses a fair amount of stack variables and not commonly called as %
• Move SelfDestruct to own method, uses a fair amount of stack variables and not commonly called (i.e max once)
• Move Return to own method, uses a fair amount of stack variables and not commonly called (i.e max once)
• Move Call to own method, uses a fair amount of stack variables and not commonly called (i.e max once)
• Use struct based Generic parameters and type checks for tracing to effectively remove all the code and the if checks from the compiled Asm when tracing is not enabled (the Jit will generate a new method for each different struct generic parameter, so can use this to make compile time if checks and then remove the branching and dead code)

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Optional. Remove if not applicable.

Remarks

Optional. Remove if not applicable.

[LukaszRozmej]

We need all tests known to man to run here (hive ect.)

Do you know what is the speedup?

Maybe all the created methods should also have [SkipLocalsInit] ?

[LukaszRozmej]

Idea - Pool those arrays between blocks?

[LukaszRozmej]

Similar here, maybe we can do some between-block Pool? Need to check all other places in VM.