Implement the HWIntrinsics for SSE4.2

[tannergooding]

category:reach
theme:intrinsics
skill-level:intermediate
cost:medium

[tannergooding]

FYI. @CarolEidt, @fiigii

I've opened this and self assigned as part of https://github.com/dotnet/coreclr/issues/15908 and https://github.com/dotnet/coreclr/issues/16216

[fiigii]

@tannergooding Thanks for the work. After finish dotnet/coreclr#16183, I plan to implement a few of SSE4.1 intrinsics as well (e.g., certain AVX helper-intrinsics need Sse41.Insert ).

[tannergooding]

@fiigii, sounds good to me.

We should probably sync up in the near future and decide how to split SSE4.1 between us.

[fiigii]

We should probably sync up in the near future and decide how to split SSE4.1 between us.

Agree, we can discuss it after dotnet/coreclr#16249 merged.

[CarolEidt]

We should probably sync up in the near future and decide how to split SSE4.1 between us.

From a logistical perspective, I propose that we leave this in the "To Do" column of https://github.com/dotnet/coreclr/projects/7, and then add sub-issues for the pieces that you plan to work on, assign them accordingly, link them here, and we can put those in the "In Progress" column. I think that will help keep track of who's working on what.

[tannergooding]

@fiigii, @CarolEidt, @eerhardt, @RussKeldorph we should set up some time to discuss the API shape for the SSE42 intrinsics.

They currently take a ResultsFlag parameter, but the flags are a result written by the instruction rather than an input to them.

However, I'm also not sure we want to be returning an enum that represents the current flag state, as that makes the instructions unnecessarily more expensive

Additionally, given that the instructions write the Arithmetic flags in a non-standard manner, we should ensure that this won't have any unexpected impact on the JIT.

All in all, I think this needs a bit more thought/work before we can start implementing them.

[fiigii]

They currently take a ResultsFlag parameter, but the flags are a result written by the instruction rather than an input to them.

I do not think the ResultsFlag is a result. We just use this flag to select the results that we want.
C++ fixes these flags in the function names, and the current .NET Core intrinsics take it as a parameter to avoid exploding APIs.

[tannergooding]

I do not think the ResultsFlag is a result. We just use this flag to select the results that we want.
C++ fixes these flags in the function names, and the current .NET Core intrinsics take it as a parameter to avoid exploding APIs.

That is very non-obvious. It also includes flags that are always reset by the instructions which leads to other confusion as well.

[fiigii]

Probably, we can just follow the C++ intrinsic design that fixes the flags in function names, which significantly simplifies the JIT implementation (especially fallback).

[fiigii]

Please close this issue.

[tannergooding]

Do we still have an issue tracking the remaining SSE4.2 APIs that still need API design/review?

[fiigii]

Yes, we have the design PR at dotnet/coreclr#19958 and related issue at CoreFX.

[tannergooding]

Closing in favor of https://github.com/dotnet/corefx/issues/30373