-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Update mono-interp to handle the same Vector.As APIs as mono-jit #104217
Conversation
Tagging subscribers to this area: @BrzVlad, @kotlarmilos |
CC. @kg this should be ready for review |
lgtm, but i'd feel better if vlad or milos also looked at it. if the regressions this is fixing don't go away, i can update the jiterpreter. |
Sounds good! This should help some, but there's some others that still need to be handled as well. I was having troubles handling them all at once in #104049, so I decided to break it apart into smaller chunks instead starting with this one. I'm going to get -- Could you give a brief explanation on the difference between the handling here and that in the jiterpreter? Does the logic not get shared between them for the SIMD acceleration? |
The jiterpreter has a generic path for interpreter SIMD opcodes that dispatches directly to the C helper, but with a wasm opcode mapping or dedicated implementation (i think this would need the latter), it can generate native jitcode directly. For this bitcast I think we'd just emit a single vector memory move. |
@BrzVlad, @kotlarmilos, this should be ready for review |
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! @BrzVlad Please sign-off before merge.
|
||
g_assert (vector_type->type == MONO_TYPE_GENERICINST); | ||
klass = mono_class_from_mono_type_internal (vector_type); | ||
g_assert ( |
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.
Should we also check the namespace?
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.
We aren't doing so in simd-intrinsics.c
, notably, but we could if desired.
I believe the expectation is that we're already only hitting this path for System.Runtime.Intrinsics
or System.Numerics
due to the higher level functions that can dispatch to these code paths.
Failure is the general timeout for this leg that is already tracked. |
This is a simplified version of #104049, trying to handle the smaller set of existing scenarios to start.