search

WebAssembly / simd

Branch of the spec repo scoped to discussion of SIMD in WebAssembly
Other
531 stars 43 forks source link

Canonical sign-replication operation #437

Open Maratyszcza opened 3 years ago

Maratyszcza commented 3 years ago

Sign-replication is an often-used operation that replicates the sign bit of a SIMD lane into all bits of the lane. There are two reasons why we need to pay attention to sign-replication. First, it can be encoded in WebAssembly SIMD in several ways:

My suggestion is:

Mapping to Common Instruction Sets

This section illustrates how the new WebAssembly instructions can be lowered on common instruction sets. However, these patterns are provided only for convenience, compliant WebAssembly implementations do not have to follow the same code generation patterns.

x86/x86-64 processors with AVX512F and AVX512VL instruction sets

x86/x86-64 processors with AVX instruction set

x86/x86-64 processors with SSE2 instruction set

ARM64 processors

ARMv7 processors with NEON extension

jan-wassenberg commented 3 years ago

@Maratyszcza Interesting. Do I understand correctly that an engine would have to check whether the shift count matches the magic value, and then emit the corresponding code? It seems that might hit branch mispredicts if mixed with regular non-magic shift operations? Is there a particular concern about adding another instruction, or are you hoping to benefit from the special case in normal shifts that happen to use the magic shift amount?

tlively commented 3 years ago

I would hope that engines would be able recognize that e.g. i8x16.shr_s(v, -1) is the same as i8x16.shr_s(v, 7). FWIW, LLVM will never emit the former and already optimizes the lt_s patterns to their shift equivalents. If these shifts-by-constant patterns are important for performance, we should certainly document a recommendation that engines treat them specially. This ties in to the documentation recommendation in #430.

Maratyszcza commented 3 years ago

Do I understand correctly that an engine would have to check whether the shift count matches the magic value, and then emit the corresponding code? It seems that might hit branch mispredicts if mixed with regular non-magic shift operations?

Engines already treat shifts with static count differently than shifts with dynamic count. What I suggest is an additional check + codegen specialization when shift count is static. Since this is a compile-time decision, no branches will be generated in the translated code.

Maratyszcza commented 3 years ago

Is there a particular concern about adding another instruction, or are you hoping to benefit from the special case in normal shifts that happen to use the magic shift amount?

We already locked the instruction proposals in November, so any new instruction proposal would have to wait until SIMD post-MVP.

dtig commented 3 years ago

We don't have a way to standardize certain immediate patterns as the standard for operations, this is something engines could optimize as described. I'll label this as perf documentation for now, and as we figure out the best way to surface this information. Perhaps in #436 if we run through other things already on the agenda.

@Maratyszcza Interesting. Do I understand correctly that an engine would have to check whether the shift count matches the magic value, and then emit the corresponding code? It seems that might hit branch mispredicts if mixed with regular non-magic shift operations? Is there a particular concern about adding another instruction, or are you hoping to benefit from the special case in normal shifts that happen to use the magic shift amount?

For this particular case, the overhead of adding operations does not seem necessary as the optimization is a special case of the shift operation and can be handled in a relatively straightforward way in the engine.

jan-wassenberg commented 3 years ago

@Maratyszcza @dtig @tlively I understand, thanks for explaining. Documentation + internal optimization in engines sounds good!