Experiment: Try to share signatures for all Wasmi bytecode executors

[Robbepop]

The Wasmi bytecode dispatcher that organizes the execution of Wasmi bytecode handles each individular Wasmi bytecode differentily. The most notable difference are:

• Fallible or infallible Wasmi instructions returning either Result<(), Error> or () respectively.
  • Examples:
    • i32.div_u: fallible
    • i32.add: infallible
• Wasmi instructions taking &StoreInner, &mut StoreInner, &mut Store<T>
  • Examples
    • Load instructions take &StoreInner
    • Store instructions take &mut StoreInner
    • Instructions that potentially call host functions take &mut Store<T>.
• Wasmi instructions that (conditionally) break out of execution returning Result<ControlFlow, Error> or ControlFlow.
  • Examples
    • Return instructions do not return ControlFlow because they always return.
    • Conditional return instructions return ControlFlow.
    • Tail calls also return ControlFlow since they might return back to the host side.

Due to this most Wasmi bytecode execution handlers have slightly varying signatures.
While this is great for performance with a single central match construct as can be seen in the link above, this really is inflexible. For example, with the current design we cannot easily transition to a tail-call based instruction dispatch once Rust supports explicit tail calls.

So this issue tracks the progress of the experiment in which we try to give all Wasmi bytecode execution handlers the same signature, taking &mut PrunedStore (amongst others) and returning Result<ControlFlow, Error>.

The main research is if we still can end up with same or nearly identical performance due to Rust's and LLVM's optimizations in the end and if it simplifies the code or is making everything even worse.

[Robbepop]

#1449 has just been merged which unblocks this issue.

[Robbepop]

A signature proposal for all instruction execution handlers could look like this:

fn handler(
    store: &mut PrunedStore,
    ip: *mut Instruction,
    sp: *mut UntypedVal,
    mem0: *mut u8,
    len_mem0: usize,
    instance: NonNull<InstanceEntity>,
) -> ControlFlow;

Where

• store is a pointer to the Wasm store which hosts all store related data.
• ip is the instruction pointer, always pointing to the instruction being executed.
• sp is the stack pointer, always pointing to the first stack slot assigned to the currently executed function.
• mem0 is the pointer to (mem 0) or nullptr if it does not exist.
• len_mem0 is the length (in bytes) of (mem 0) or 0 if it does not exist.
• instance is a pointer to the currently used Wasm instance for faster access than through store.
• ControlFlow is an enum that can be one of the following states:
  • Continue: continue execution with the next instruction pointed to by ip
  • Break: discontinue instruction execution, yielding a result or an error.
    • Errors are stored in the store context so that ControlFlow can stay small.

Once #1492 is merged we can remove the instance parameter since then all Wasmi bytecodes are already associated to a specific instance. This allows us to use the 6th parameter for a future addition of operand registers.