Add V128 SIMD value type

[bnason-nf]

Referencing a comment here:

#3363 (comment)

@wenyongh suggested that a 128 bit vector type should be added to the value type enum for SIMD support. This change adds an item to the relevant enums, and also adds code in various places to support that enum item. Please let me know if I missed anything.

Note that this requires changing the union inside the wasm_val_t structure to add a v128 member, which increases the overall size of the structure. As far as I can tell that doesn't cause any compatibility issues, even with AOT, but I'm not confident about that.

[lum1n0us]

I am not sure about that but it's a little confused to keep both union V128 and union wasm_v128_t, especially when they are sharing the same definition.

[bnason-nf]

I'm happy to change them to use the same name. Which do you prefer? I'm not completely sure about the naming rules, but using the name V128 in wasm_export.h didn't feel correct.

[wenyongh]

Referencing a comment here:

#3363 (comment)

@wenyongh suggested that a 128 bit vector type should be added to the value type enum for SIMD support. This change adds an item to the relevant enums, and also adds code in various places to support that enum item. Please let me know if I missed anything.

Note that this requires changing the union inside the wasm_val_t structure to add a v128 member, which increases the overall size of the structure. As far as I can tell that doesn't cause any compatibility issues, even with AOT, but I'm not confident about that.

@bnason-nf is there any requirement from you to get v128 param/result type from func type? This really causes AOT ABI compatibility issue, the aot compiler assumes that the sizeof(wasm_val_t) is 16 when enabling the wamrc --invoke-c-api-import option:
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/core/iwasm/compilation/aot_emit_function.c#L360-L373

https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/perf_tune.md#82-refine-callings-to-native-apis-registered-by-wasm-c-api-wasm_instance_new-from-aot-code

This PR means that the old AOT file generated by wamrc --invoke-c-api-import may be unable to run with new aot runtime since the offset isn't consistent.

[bnason-nf]

@wenyongh yes that's what I was concerned about. However, this change is confusing to me then. Is the goal to add v128 to the value type enum, but not add v128 to the value type itself? Is there a use case for that?

[wenyongh]

@wenyongh yes that's what I was concerned about. However, this change is confusing to me then. Is the goal to add v128 to the value type enum, but not add v128 to the value type itself? Is there a use case for that?

@bnason-nf I think adding WASM_V128 to wasm_valkind_enum is good, and also we can enhance wasm_func_type_get_param_valkind/wasm_func_type_get_result_valkind. But for how to support v128 in wasm_val_t, there was discussion and it hasn't been supported in wasm-c-api and other runtimes yet, see:
WebAssembly/wasm-c-api#106
https://github.com/bytecodealliance/wasmtime/blob/main/crates/c-api/src/val.rs#L120

I think we had better keep wasm_val_t unchanged and seek better solution in the future.

For wamrc --invoke-c-api-import example, please refer to samples/wasm-c-api-import:
https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/samples/wasm-c-api-imports/wasm/CMakeLists.txt#L34

[bnason-nf]

I see, thanks for the explanation. I've removed v128 from wasm_val_t.

[wenyongh]

LGTM

[bnason-nf]

@wenyongh do you know why the checks for this PR are not running?

[lum1n0us]

LGTM

[wenyongh]

@wenyongh do you know why the checks for this PR are not running?

It is really strange, I have re-run the CIs manually.