Local set and get for V128

[Zzzabiyaka]

Hi @wenyongh @lum1n0us @loganek @jammar1
I’m currently implementing local.set / get for v128 to finish off the simd work for fast interpreter

I looked at how it’s done for 32 and 64 bit types and I see that we use separate opcodes for that

https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/interpreter/wasm_opcode.h#L255

The easiest way for me then would be to add the similar opcode for v128 (EXT_OP_SET_LOCAL_FAST_V128)
and do the handling in fast_interp (extending https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/interpreter/wasm_loader.c#L12927) , however I have no opcode space (i.e. all 0xc opcodes are already used)

I think my options are pretty much limited to:

1. Handle WASM_OP_GET_LOCAL in the interpreter (e.g. don’t fast-process it in loader for V128)
2. Introduce new opcodes like EXT_OP_SET_LOCAL_FAST_V128. I am not sure whether it’s a safe thing to do but I would probably avoid doing it
3. I probably can emit 2 opcodes EXT_OP_SET_LOCAL_FAST_I64 instead of V128. I think it's going to be quite confusing and risky if possible at all

I think I should stick to option 1 but wanted to gather your opinion first

[lum1n0us]

Personally, I would prefer to create a new two-level structure specifically for WAMR's private opcodes. In this scenario, we would only require one slot in the enum WASMOpcode and would have a full range of 255 options to choose from.

The issue with local set/get for v128 simply highlights a potential problem. Even if we find a workaround now, it's likely that a similar issue will arise again in the future.