[SIMD] wasm2wat reports unexpected opcode: 0xfd 0x3 for wasm_v8x16_shuffle

[huningxin]

wasm_v8x16_shuffle is widely used in OpenCV.js universal intrinsic implementation, e.g. v_interleave_quads. However, if the code uses wasm_v8x16_shuffle and compiles to wasm, the wasm2wat tool will report unexpected opcode: 0xfd 0x3 for that wasm file. According to https://github.com/WebAssembly/simd/blob/master/proposals/simd/BinarySIMD.md, there is no opcode 0xfd 0x3.

This issue blocks the wat based analysis of OpenCV.js SIMD optimization.

v_interleave_quads.cc:

#include <wasm_simd128.h>
#include <stdio.h>

__attribute__((noinline))
inline __i8x16 v_interleave_quads(const __i8x16& vec)
{
    return wasm_v8x16_shuffle(vec, vec, 0,4,1,5,2,6,3,7,8,12,9,13,10,14,11,15);
}

int main() {
    __i8x16 a= wasm_i8x16_make(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15);
    __i8x16 b = v_interleave_quads(a);
    printf("%d \n", wasm_i8x16_extract_lane(b, 0));

    return 0;
}

compile it by

emcc -O2 -g2 -msimd128 -o v_interleave_quads.html v_interleave_quads.cc

wasm2wat log:

$ wasm2wat --enable-all -o v_interleave_quads.wat v_interleave_quads.wasm
000027e: error: unexpected opcode: 0xfd 0x3

[tlively]

The SIMD proposal was updated to renumber that instruction after it was implemented in LLVM. I will do more LLVM work to bring it up to date with the proposal soon, but in the meantime perhaps you can use Binaryen's wasm-dis tool to get unstuck.

[huningxin]

Binaryen's wasm-dis just works. Thanks @tlively .

[VirtualTim]

Relates to #9340.

[abrown]

@tlively, I am running into this issue with emcc --version:

emcc (Emscripten gcc/clang-like replacement) 1.39.8 (commit 1458145cf4f3db0fb548343e6acab267eef8e4ef)

Is this already fixed in LLVM and I need to use tot or does this still need to be fixed in LLVM? (If the later, just point me to the general area and I'll take a look).

[tlively]

@abrown If I understand correctly, you are also experiencing an issue with wabt using a different opcode for shuffles. If that is the case, I still recommend using Binaryen's wasm-dis instead. I'm not sure how Emscripten or LLVM are involved. Can you elaborate?

[abrown]

Shouldn't Emscripten/LLVM emit 0xfdc1 instead of 0xfd03? I'm wondering when (if?) that will be changed to reflect the current numbering.

[tlively]

Ah, I see. It's basically not worth the effort of renumbering that single instruction in all of the tools and engines. Whenever we renumber anything, there is some period of time where users have to jump through extra hoops to get all their tool and engine numbers to match. We will do a global renumbering once we resolve all outstanding discussions and freeze the feature set, so we will have just a single breakage period for all the instructions at once.

[abrown]

Ok, that makes sense; perhaps I could ask wabt to parse both 0xfdc1 and 0xfd03 to shuffle in the meantime. wasmparser.rs does exactly that which is why I haven't seen this until now.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.