-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Updating Vector<T> to support nint and nuint #50832
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
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
b686f43 to
f3be3d6
Compare
3053f08 to
755f6e0
Compare
|
@fanyang-mono, could you assist with the mono failures here? It looks like there are two kinds of failures:
Related, it looks like Mono has some hard-coded logic around The latter two issues look fairly straightforward to resolve, I'm just not familiar with what the correct |
|
I'm not sure I understand this, they are just aliases for |
|
IntPtr/UIntPtr is MONO_TYPE_I/MONO_TYPE_U. |
If that's the case, they should be mapped to |
|
I believe I've fixed the first issue (70432e5):
and the third issue (c3107e0):
I've also fixed part of the second issue (also c3107e0):
The remainder of the second issue looks to be that a couple code paths will still assert ( |
Maybe something like this |
|
I believe the relevant mono paths are now updated to correctly handle |
|
CC. @echesakovMSFT, @dotnet/jit-contrib for review |
|
The mono changes look ok to me. |
… functions for Numerics vs Intrinsics
…vially pulled from the operand instead
…rowForUnsupportedNumericsVectorBaseType and ThrowForUnsupportedIntrinsicsVectorBaseType
…_U` on relevant code paths
8ada17b to
c150826
Compare
|
Rebased to resolve a conflict, believe I've also resolved the remaining ARM64 issue (it passed on my Windows box). |
|
Everything is passing now except for two LLVM AOT scenarios. It isn't clear to me what's wrong here given that the regular Mono leg passed. @vargaz or @fanyang-mono, could you provide some guidance on how to root cause the failure here? |
|
Actually, I may have found it, there is a single line calling out an assert about halfway through the log:
|
|
Only test failures are unrelated and due to #51346 This should be ready for final review/merge. |
|
My small contribution to the review: commit 57fc73d LGTM! |
echesakov
left a comment
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.
LGTM
Thank you for your contribution, @tannergooding!
cc @dotnet/jit-contrib
This resolves #36160
In order for this to work,
GenTreeJitIntrinsicwas updated to track the baseType as aCorInfoTyperather than as avar_types(as discussed in #36160 (comment)). There is additionally a newJitType2PreciseVarTypemethod which ensures that aCorInfoTypeis converted to avar_typesin a way that preserves the sign (JITtype2varTypewill convertCORINFO_TYPE_UINTtoCORINFO_TYPE_INTotherwise).I ran
jit-diff --pmifor--frameworks,--benchmarks, and--testsafter the second commit to ensure there were no diffs due to the above changes. I then added the three latter commits supportingVector<nint>andVector<nuint>.Edit: The vast majority of the PR is hardware intrinsic tests being added via the
NotSupportedtemplate (so they are auto-generated, like most of the hwintrinsic tests).Review of the PR can be simplified by just reviewing one of the generated tests since they all follow the same pattern.
Edit: This work was completed:
I am marking this as a draft until I can get some more tests up, including negative validating fornint/nuintonVector64/128/256<T>.I will also take a look at updating the couple places where we still haveusing nuint_t = System.UInt64, such as inUtf16Utility.Validation.cs