Codegen of i16x8.relaxed_laneselect

[alexcrichton]

Currently in #17 it's suggested that the x86_64 lowering of the i16x8.relaxed_laneselect instruction is pblendvb, and this appears to be what v8 does today. In #115 (plus the current Overview.md), however, the english prose for the definition of this instruction is:

Relaxed lane selection is deterministic when all bits are set or unset in the
mask. Otherwise depending on the host, either only the top bit is examined, or
all bits are examined (i.e. it becomes a bit select).

I don't believe, though, that the pblendvb instruction correctly implements these semantics because lane selection mask 0x0080 that's neither 0x0000 or 0xffff and the high bit is zero, meaning that according to the spec the output should be the element in the b vector. The pblendvb instruction works at the byte-level, though, so one byte will be chosen from the a vector and one will be chosen from the b vector.

I think that this is also an issue with v8's lowering of the i{32x4,64x2}.relaxed_laneselect since they all go through pblendvb right now, although the suggestion in #17 I think would work with blendvp{s,d} instead.

[Maratyszcza]

This is a good point! The intention is to allow i16x8.relaxed_laneselect to lower to pblendvb.

[alexcrichton]

I'm not intimately familiar with the motivations, but if the intention is to basically give users a choice of bsl on AArch64 and pblendvb on x86_64, then would it make sense to remove the i16x8, i32x4, and i64x2 versions? The current Overview.md I think is correct for the i8x16 case when pblendvb is used as an implementation and if the other types use the same lowering on v8 then the other types may not be necessary?

[dtig]

This maybe a bug in the baseline compiler, thanks for flagging. Here's how the optimizing compiler handles it.

[alexcrichton]

Oh! Sorry I naively assumed they'd be similar, should have checked both!

For your link @dtig though if I'm reading that right it's only different in using blendvp{s,d} for i{32x4,64x2}.relaxed_laneselect, but for i16x8 it's still using pblendvb which suffers from this issue?

[dtig]

Oh! Sorry I naively assumed they'd be similar, should have checked both!

This is the right assumption, and should be true in most cases except for where we emit extra instructions because we can't specify register constraints in the baseline compiler. The basic functionality or the variants of the instructions should be the same. Hopefully there aren't many other cases where they don't match like they should. :)

For your link @dtig though if I'm reading that right it's only different in using blendvp{s,d} for i{32x4,64x2}.relaxed_laneselect, but for i16x8 it's still using pblendvb which suffers from this issue?

You're correct that I was only responding to the i{32x4,64x2}.relaxed_laneselect bit. Working through the example in the OP, for the case where all the bits are set (deterministic output), everything works as expected, but for the case you outlined, pblendvb wouldn't work as detailed in the prose spec. It would be simple to massage the mask to only examine the top lane bit for the i16x8 case to adhere to the spec. But from @Maratyszcza message here, maybe the prose may not be indicative of the intent? My interpretation is that the result is only guaranteed for 0x0000 or 0xffff, and for no other values of the mask. I'm fine with either formulation, but we should pick one for consistency.

[ngzhian]

Think this will get pretty ugly: we will have to special case i16x8, and have it check specifically for 0x0080 to 0x00FF, and return a mix of the top and bottom half. For reference, the spec for relaxed lane select is here: https://www.ngzhian.com/relaxed-simd/core/exec/numerics.html#xref-exec-numerics-op-relaxed-lane-mathrm-relaxed-lane-n-i-1-i-2-i-3

[Maratyszcza]

We could change the text as follows: "Relaxed lane selection is deterministic when all bits are set or unset in the mask. Otherwise depending on the host, either only the top bit of a lane is examined, only the top bit of each byte is examined, or all bits are examined (i.e. it becomes a bit select)."

This change would allow using PBLENDVB for 16-bit laneselect (also allow using PBLENDVB for other laneselects, but that option is not interesting).

[alexcrichton]

Would it be possibility to drop the i16x8.relaxed_laneselect intrinsic entirely? If the goal is to get the generated instruction on x86_64 to be pblendvb then that's already achievable with i8x16.relaxed_laneselect. If the spec wording is updated to allow i16x8.relaxed_laneselect to have this implementation then there's no need for the instruction itself as other instructions already generate equivalent lowerings.

[ngzhian]

I'm not opposed to removing i16x8.relaxed_laneselect, but it makes the instruction set a bit asymmetrical. Having to explain why we don't have that instruction is also weird:

• "Why don't we have i16x8.relaxed_laneselect?"
• we want it to be pblendvb, and we already have a i8x16.relaxed_laneselect
• "isn't pblendvb a valid implementation of i32x4.relaxed_laneselect then? why do we have i32x4.relaxed_laneselect?"
• because i32x4.relaxed_laneselect is implemented as blendvps

So maybe we want to change the wording, but keep all instructions, to allow for some implementation wiggle room.

[alexcrichton]

I don't disagree that symmetry is nice, but when it comes to wasm simd I think the ship might have already sailed on that? For example i64x2 unsigned comparisons are not present, there's no extadd_pairwise for i64x2 outputs, there's no i32x4.narrow_*, etc. I haven't been intimately involved with SIMD historically but it seems like the instruction set is strongly driven by concrete "what's in hardware and what do people need" motivations rather than symmetrical "let's hope hardware makes this fast" wishes. Given that, at least from my own (possibly naive) perspective, a missing instruction like this is expected and normal. Or, in other words, explaining missing instructions seems like something that's already required and having one more hole seems like it's almost expected rather than rationale to keep something.

Alternatively why not go one step further? If the goal is to get access to pblendvb on x86_64 why have i{32x4,64x2}.relaxed_laneselect? If there are concrete use cases which want blendvp{s,d} it seems reasonable to have them, but if they were themselves purely added for symmetry with i8x16 and the only original goal was pblendvb then it seems like a possibility is to only have the i8x16 variant.

[ngzhian]

We should probably discuss this at the next sync, unfortunately I'm OOO that day. (And Marat is also OOO).
@penzn will you be around to run the sync this Friday, we should bring this up for discussion.

Okay I just checked, XNNPack has some code (not in production yet) that checks if i32x4.laneselect is implemented using blendvps (i.e. only checks top bit). So it is still useful (e.g. detectsign of floats)

[penzn]

Sorry for the late reply. We should schedule a sync I think.