Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Adding support to mono for v128 constants #81902
Adding support to mono for v128 constants #81902
Changes from 4 commits
f3f0340
046ddc9
ed988af
e21a876
1fa29d7
cef739e
c94cb5c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
AFAIK, there isn't any SIMD support for BE architectures today.
It's possibly this needs to track the underlying element type and splat each
T
in memory correctly instead.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.
As per the FIXME comment below, the alignment here only needs to be
8
fordouble
and4
forfloat
. But some other logic was utilizing R4/R8 for packed SIMD instructions.That should ideally be fixed and those updated to properly use X128 constants to save on space and help ensure correctness.
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.
Just wanted to leave a more general comment that Mono currently has to do these class name and type checks to determine things.
It would be beneficial if there was a way to track that the
simdType
andsimdBaseType
. In RyuJIT, we haveTYP_SIMD8/12/16/32/64
and we then track the primitive base type as a separate field.This allows better codegen, better specialization, and all-over cheaper checks. Even if this was just some helper method that cached a
klass
tosimd info
lookup, I think it would improve/simplify things.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.
There is a simd_class_to_llvm_type () function which can be used here.
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.
Thanks for the reference @vargaz!
I'm not sure that really addresses the backing issue of there still needing to be string comparisons to do the checks in the first place and it doesn't help things on the MonoJIT side.
My comment was more about the general cost of going from a
klass
to the respectiveSimdType
andSimdBaseType
and how if Mono had a different way to track this it could be done cheaply once at import.Subsequent handling, including
simd_class_to_llvm_type
could then be made cheaper.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 is how the hashes are currently being built for R4/R8, but they don't necessarily make "sense" to me.
This isn't a "good" hash since it just
or's
bits together, it doesn't take into account the "upper bits", and it relies on undefined behavior in the case thedouble
orfloat
isNaN
/Infinity
/out of range
.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.
It's not the best, but its just used during JITting/AOTing, so it's not a problem in practice.