[jit] Add more SSE2 opcodes. Enable SSE2.

[vargaz]

No description provided.

[EgorBo]

Disable SSE2 support as some intrinsics are still missing.

Looks like the following are missing:

ConvertScalarToVector128Double
ConvertScalarToVector128Single
ShiftLeftLogical
ShiftRightLogical

LGTM since IsSupported is disabled

[EgorBo]

@tannergooding do you happen to know how coreclr handles intrinsics which require constant args and a variable is passed instead? e.g.

Vector128<int> Foo(Vector128<int> lhs, byte rhs)
{
    return Sse2.Shuffle(lhs, rhs);
}

[tannergooding]

do you happen to know how coreclr handles intrinsics which require constant args and a variable is passed instead

If the value is constant, we just return a gtNewSimdHWIntrinsicNode immediately. Otherwise, we return nullptr which forces a standard call node to be emitted.
When it becomes time to generate code for the call, we'll see it is recursively calling itself (tracked via mustExpand) and we'll return a gtNewSimdHWIntrinsicNode node in that case anyways.
This is done to support indirect calls (delegates, reflection, debugger, etc) as well as instructions that require a constant input for their operand (such as shufps).

When it gets to codegen, we then check if the value is constant again, for example see here.
If the value is constant, codegen can happen normally and we just emit the instruction. However, if it isn't we go to genHWIntrinsicJumpTableFallback and emit a jump table containing all possible scenarios (up to 256) and hard code the constants in the table.

The fallback is slow, but it ensures things will work in various edge scenarios and devs using HWIntrinsics should be profiling so they'll catch the issue. We've previously discussed an analyzer as something that could help flag non-constant inputs to the user as well, but that hasn't been implemented yet. We also have an issue (#11062) tracking us delaying the mustExpand decision until later (such as in lowering) so we can cover more constant input cases, but that will require some more work in the JIT.

CC. @CarolEidt, @echesakovMSFT

[EgorBo]

However, if it isn't we go to genHWIntrinsicJumpTableFallback and emit a jump table containing all possible scenarios (up to 256) and hard code the constants in the table.

Thanks, so it's basically the same as what Zoltan did (not sure about the 256 limit). I see that all imm arguments are of byte type in C# API for that :) even if it's int in the C API, e.g..

        /// <summary>
        /// int _mm_extract_epi16 (__m128i a,  int immediate)
        ///   PEXTRW reg, xmm, imm8
        /// </summary>
        public static ushort Extract(Vector128<ushort> value, byte index) => Extract(value, index);

And I guess we can always emit a jump table even for a const input -- LLVM will optimize it anyway (but probably makes sense to handle const to reduce compilation time)

[tannergooding]

I see that all imm arguments are of byte type in C# API for that :) even if it's int in the C API

Yes, because the underlying instruction only accepts an imm8 (hence why 256 is also the upper limit of the number of jump table scenarios).