-
Ng Zhi An authored
Previously, we fixed the decoding of SIMD opcodes >= 0x80 that reads an immediate. However, we left behind a TODO for SIMD opcodes <= 0x80. This fixes it. Given a byte sequence such as [0xfd, 0x80, 0x80, 0x0], it decodes to the SIMD opcode S128LoadMem (the last 3 bytes decode to 0, it is not the most efficient encoding, but is still valid). Then, when we are decoding the immediate memarg that follows this, we need to skip ahead 3 bytes (opcode_length). We were not doing that previously. This patch changes the signature of SimdLaneImmediate and Simd8x16ShuffleImmediate to make this requirement clearer. It takes a new argument opcode_length, which is the number of bytes the LEB encoded opcode takes up. The pc should then be passed in unchanged. In function-body-decoder-impl.h, we also consistently pass down opcode_length into the various helpers, and use that value to decode immediates. Changes have been made to wasm-interpreter to record the opcode_length to be passed down to helpers. Bug: chromium:1075719 Bug: v8:10258 Change-Id: I502c9ef47d4da2abadf14218bf0da19b291ec55c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2171460Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67483}
6f48a0e0