-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: Encode SIMD base type in VN for all HW intrinsics #105869
Conversation
cc @dotnet/jit-contrib PTAL @tannergooding I went with your suggestion to just encode the SIMD base type for all HW intrinsics, and removed all the references to the old stuff. The diffs (from the run before I pushed the test) are miniscule so definitely seems like the right direction to go here. |
👍, mostly looks to be around bitwise operations (and, or, xor, not, ternlog, etc). Users have the ability to manually workaround for these if its important in .NET 9 and mixing types to that degree is relatively rare, so I wouldn't expect most code to be pessimized by this. Should be easy to improve the select cases in .NET 10. |
normalPair = vnStore->VNPairForFunc(tree->TypeGet(), func); | ||
assert(vnStore->VNFuncArity(func) == 0); | ||
} | ||
// There are zero arg HWINTRINSICS operations that encode the result type, i.e. Vector128_AllBitSet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is notably out of date, we produce GT_CNS_VEC
for cases like AllBitsSet
now. Off the top of my head, other zero arg intrinsics should also be getting converted to constant nodes and I'm not sure any cases actually exist that can hit this anymore.
Should be safe to leave in for .NET 9, but might be something we can cleanup early in .NET 10
We're getting failures on all the SVE tests. We suspect it's this PR, but just confirming...
|
Seems likely, sorry about that. How do I run those tests? |
Although, the failing test was presumably added in #105595, so it might be an unlucky conflict with this PR (this PR went in shortly before that one). |
Hi @jakobbotsch , the same issue is also observed for other intrinsics. I checked the
Here, |
This changes the VN funcs for all HW intrinsic functions to always have an extra parameter for the SIMD base type. Before this change it was based on the instruction list, however that is not always the right thing (e.g. #105721 is a bug because of that). We also kept it as part of the HW intrinsic table, but that requires manual maintenance and is easy to get wrong. Always encoding the type is much more simple and the diffs do not look too bad.
In .NET 10 we can decide if we want to opt some intrinsics into not being differentiated based on the SIMD base type. The easiest thing might be to always map those to have the same base SIMD type (e.g.
CORINFO_TYPE_BYTE
) so that we don't end up with differences in arities for some VN functions that are hard to reason about.Fix #105721