-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[Arm64] Treat methods of non-generic Vector64 and Vector128 classes as intrinsics #40441
[Arm64] Treat methods of non-generic Vector64 and Vector128 classes as intrinsics #40441
Conversation
b35f272
to
56af646
Compare
src/coreclr/src/zap/zapinfo.cpp
Outdated
// On Arm64 AdvSimd ISA is required by CoreCLR, so we can expand Vector64<T> and Vector128<T> generic methods (e.g. Vector64<byte>.get_Zero) | ||
// as well as Vector64 and Vector128 methods (e.g. Vector128.CreateScalarUnsafe). | ||
fTreatAsRegularMethodCall |= !fIsPlatformHWIntrinsic && fIsHWIntrinsic | ||
&& (strstr(className, "Vector64") != className) && (strstr(className, "Vector128") != className); |
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 condition could be checked more accurately by
(strcmp(className, "Vector64") != 0) && (strcmp(className, "Vector64`1") != 0) && (strcmp(className, "Vector128") != 0) && (strcmp(className, "Vector128`1") != 0)
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.
why strstr
rather than strncmp
?
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.
why
strstr
rather thanstrncmp
?
@tannergooding What do you mean?
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.
strstr
checks the entire string and is more complex, so if you have strstr(className, "Vector64")
and className
happend to be "SomeTextVector64", it wouldn't exit on S
and would instead keep searching and match Vector64
at the end, returning the new index.
strncmp
allows you to check for "Vector64"
or "Vector128"
, from the start of the string and terminate at a given digit count. This means you know it starts with exactly that text and if desired you can easily check if the returned index is '\0'
or if it is "``1"
)
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.
Makes sense
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.
@tannergooding I did as you suggested - replaced strstr
with strncmp
. PTAL
@dotnet/jit-contrib @tannergooding @davidwrighton Can you please take a look? |
@davidwrighton Just to clarify things a bit that the changes are not related to our discussion in #32714. The methods were enabled to be treated as intrinsics on Arm64 a while ago under assumption that AdvSimd is required baseline (in #38060). |
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 catching it.
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 - thanks!
…sName startswith "Vector128"` in zapinfo.cpp
I noticed that condition I added in #39753 for computing
fTreatAsRegularMethodCall
in zapinfo.cpp based on class name was too strict - it made all methods of non-genericVector64
andVector128
classes to be treated as regular methods.Unfortunately, I didn't notice this back then since the same PR stopped generating bodies of hardware intrinsic methods on Arm64 and, as a consequence, the total size of System.Private.CoreLib native image still went down.
I believe, this should be resolved after this change.
System.Private.CoreLib.ni.dll - 12,078,080 bytes before
System.Private.CoreLib.ni.dll - 12,073,472 bytes after
As an example, what this change does
Before:
After: