ghost
commented
1 year ago Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics See info in area-owners.md if you want to be subscribed.
Issue Details
## Summary While implementing the API surface for [Expose VectorMask
Summary
While implementing the API surface for Expose VectorMask to support generic masking for Vector , various considerations were found that necessitated taking a step back and reconsidering how it works.
Most of these issues were found foremost in the additional complexity and throughput hit that was going to be required for the JIT to integrate the type. However, it also impacted the way users interacted with the types and the public API surface we were to expose. Namely that existing user code would not benefit and it would nearly double the API surface we're currently exposing for the XArch and cross-platform intrinsics.
These considerations were raised with @dotnet/avx512-contrib and an alternative design was proposed where the JIT would do pattern recognition in lowering instead to limit the throughput hit and provide light-up to existing user code. This does not preclude the ability to expose
VectorMaskin the future and we can revisit the type and its design as appropriate.Conceptual Differences
Previously, we would have defined the following and this would have expanded to effectively all existing intrinsics exposed. This would nearly double or triple our API surface taking us from the
~1900APIs we have today up to at least~3800APIs. Arm64, as a corallary example, currently has~2100APIs.Pattern Recognition
Rather than exposing these overloads of APIs that take
VectorMask<T>and allowing users to explicitly utilize masking, we will instead recognize a few key patterns and transform those in the JIT instead.We would of also had some intrinsics such as
public static Vector512Mask<float> CompareEqual(Vector512<float> left, Vector512<float> right)which produce a mask and various other ways to produce a mask as well. Developers then would've been able to consume this by passing down the mask to the API. For example, in the following we find all additions involvingNaNand ensure those elements become0in the result.If a user wanted to do that today where masking doesn't exist, they'd actually do a functionally similar thing:
Thus, by instead recognizing these patterns we can light up existing code and avoid exploding the API surface while also ensuring that the code users aim to write is consistent regardless of whether they are on hardware with native hardware masking or not.
A sampling of the set of patterns we want to recognize include, but are not limited to:
{k1} - ConditionalSelect(mask1, resultVector, mergeVector){k1}{z} - ConditionalSelect(mask1, resultVector, Vector.Zero)kadd k1, k2 - mask1.ExtractMostSignificantBits() + mask2.ExtractMostSignificantBits()kand k1, k2 - mask1 & mask2kandn k1, k2 - ~mask1 & mask2kmov k1, k2 - mask1 = mask2kmov r32, k1 - mask1.ExtractMostSignificantBits()kmov k1, r32 - Vector.Create(...).ExtractMostSignificantBits()knot k1, k2 - ~mask1kor k1, k2 - mask1 | mask2kortest k1, k2; jz - (mask1 | mask2) == Vector.Zerokortest k1, k2; jnz - (mask1 | mask2) != Vector.Zerokortest k1, k2; jc - (mask1 | mask2) == Vector.AllBitsSetkortest k1, k2; jnc - (mask1 | mask2) != Vector.AllBitsSetkshiftl k1, k2, imm8 - mask1.ExtractMostSignificantBits() << amountkshiftr k1, k2, imm8 - mask1.ExtractMostSignificantBits() >> amountktest k1, k2; jz - (mask1 & mask2) == Vector.Zeroktest k1, k2; jnz - (mask1 & mask2) != Vector.Zeroktest k1, k2; jc - (~mask1 & mask2) == Vector.Zeroktest k1, k2; jnc - (~mask1 & mask2) == Vector.Zerokunpck k1, k2, k3 - UnpackLow(mask1, mask2)kxnor k1, k2 - ~( mask1 ^ mask2)kxor k1, k2 - (mask1 ^ mask2)vpbroadcastm - Vector.Create(mask1)vpmovm2* - mask1.ExtractMostSignificantBits()vpmov*2m - vector1.ExtractMostSignificantBits()API Proposal