simdsignunsignedextendedload.md

[rrwinterton]

proposes 8, 16, 32 signed and unsigned extended load instructions.

[dtig]

Thanks for creating the PR! Please add the new proposed instructions to SIMD.md in their own section, and include them in BinarySIMD.md with proposed opcode numbers as well. The Spec should be architecture agnostic, so while the details about Intel/ARM instructions are useful, I think they are documented well in the existing documentation in the issue, and don't need to be in the Spec.

[gnzlbg]

The instruction multiples 32 8-bit integers, 16 integers from the first register with 16 integers from the second register, resulting in 16 8-bit integers.

[gnzlbg]

typo: it -> is

---

Also what do you mean with the distribution of the integers being flat? And even if that is the case, does it always result in overflow? e.g., if all integers are 0, then the distribution would be as flat as it gets but no overflow would happen.

[gnzlbg]

i8x16.mul implements wrapping integer multiplication, therefore, I don't see why overflow there is a problem (as in the behavior of these on overflow is well-defined, its neither an error nor UB), and wrapping multiplies is a very common and desirable operation to provide (the text reads a bit like "wrapping multiply is bad").

[gnzlbg]

Nowhere does the text say what the proposed instructions actually do, what are their argument types, results, operational semantics, etc.

[gnzlbg]

Please show WASM instead.

[gnzlbg]

All these types are 64-bit wide vector types, but the spec does not define v64 anywhere.

[gnzlbg]

I find the document and the issue quite unclear, so I might be completely misunderstanding what problem this is trying to address, but if what you want is to be able load, e.g., 4 x 16-bit integers into a v128 containing 4 x 32-bit integers by sign or zero extending them, then I would prefer something that's more similar to the scalar intrinsics, e.g., like i32x4.load_i16x4_s(memarg) -> v128.

[dtig]

I think the intent here is to introduce something equivalent to the intel pmovzx(b/d/q) instruction, so the operation would be as follows -

Packed_Zero_Extend_BYTE_to_WORD(DEST, SRC)
DEST[15:0] <- ZeroExtend(SRC[7:0]);
DEST[31:16] <- ZeroExtend(SRC[15:8]);
DEST[47:32] <- ZeroExtend(SRC[23:16]);
DEST[63:48] <- ZeroExtend(SRC[31:24]);
DEST[79:64] <- ZeroExtend(SRC[39:32]);
DEST[95:80] <- ZeroExtend(SRC[47:40]);
DEST[111:96] <- ZeroExtend(SRC[55:48]);
DEST[127:112] <- ZeroExtend(SRC[63:56]);

So it's not strictly a V128->V128 operation. I do agree that this would benefit from clearer names instead of zx/sx convention that's not very readable.

[gnzlbg]

typo: backticks missing

[gnzlbg]

typo: line break

[gnzlbg]

typo: line break

[gnzlbg]

typo: line break

[gnzlbg]

Please link the issue (#28) and the rendered document in the top-level comment.

[penzn]

I believe we have populated the opcodes and instruction descriptions in this PR. One thing to note is that it implements #28 and not #21 (latter proposes vector to vector operations).

[dtig]

Did you mean to include the packed versions of these instructions (ex: pmovzxbw/pmovsxbw)? Please link the exact instruction you mean if that's not the one.

[dtig]

Can this document be removed? While this is useful information, I don't see a need for this to be included here.

[penzn]

Do you want it to be included in the body of the PR or just simply remove it? @rrwinterton, what do you think?

[dtig]

Can this be made clear here that this is not operating on 64bit widths widening to a 128-bit vector? Having a concise description here will be useful.

[penzn]

Do you mean to clarify that we are extending every lane, rather than widening a 64-bit value?

[penzn]

The description of the change (so that we can delete the file):

Proposed new instructions

Six new load instructions are being proposed to make integer multiplies easier. i8x16.zxload, i8x16.sxload, i16x8.zxload, i16x8.sxload, i32x4.zxload, i32x4.sxload. This would make i8, i16, i32 multiplies useful and more practical for applications such as machine learning, image compression and video and rendering data processing. The new instructions would take consecutive integers of the corresponding size and zero sign extend and sign extend the consecutive bytes, words or dword to the promoted size of signed or unsigned data. An example of zero sign extend is shown below: Intel and ARM both have this capability by doing the following:

Intel Instructions:

• movzxbw
• movzxwd
• movzxdq
• movsxbw
• movsxwd
• movsxdq

ARM Instructions:

• LDR X0, [X1] Load from the address in X1
• LDR X0, [X1, #8] Load from address X1 + 8
• LDR X0, [X1, X2] Load from address X1 + X2
• LDR X0, [X1, X2, LSL, #3] Load from address X1 + (X2 << 3)
• LDR X0, [X1, W2, SXTW] Load from address X1 + sign extend(W2)
• LDR X0, [X1, W2, SXTW, #3] Load from address X1 + (sign extend(W2) << 3)

So the new instructions for WASM would be defined as follows:

• i8x8.zxload
• i16x4.zxload
• i32x2.zxload
• i8x8.sxload
• i16x4.sxload
• i32x2.sxload

As a result of these new instructions a multiply can now be done without worrying about signed

and unsigned overflow on the data it operates on.

The following is a partial sample example of how sign extended loads are be used in a matrix multiply of 8 bit integers:

       "pmovzxbw 0x00(%[mem]), %%xmm0\n\t"
       "pshufd $0x00,%%xmm1,%%xmm2     \n\t"
       "pshufd $0x55,%%xmm1,%%xmm3     \n\t"
       "pmaddwd %%xmm0, %%xmm2         \n\t"
       "pmaddwd %%xmm0, %%xmm3         \n\t"
       "paddd %%xmm2, %%xmm4           \n\t"
       "paddd %%xmm3, %%xmm5           \n\t"

[AndrewScheidecker]

These names would be more consistent with the scalar extending load instructions (i.e. i32.load8_s):

original	alternative 1	alternative 2
i8x8.zxload	i16x8.load8x8_u	i16x8.load8_u
i16x4.zxload	i32x4.load16x4_u	i32x4.load16_u
i32x2.zxload	i64x2.load32x2_u	i64x2.load32_u
i8x8.sxload	i16x8.load8x8_s	i16x8.load8_s
i16x4.sxload	i32x4.load16x4_s	i32x4.load16_s
i32x2.sxload	i64x2.load32x2_s	i64x2.load32_s

[tlively]

Thanks for those suggestions, @AndrewScheidecker! I personally prefer alternative 1 because they are more explicit about how much memory is actually being loaded.

[penzn]

I like that scheme as well, incorporated in rrwinterton#4