-
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
Use Unsafe.WriteUnaligned
in BitConverter.GetBytes
#91639
Conversation
Similar changes should also be made in #91299. |
|
I appreciate the effort, but what is the concrete benefit of this change? A total of 20 bytes of IL and 0 impact on the resulting asm? If that's all this buys, I don't think it's worth the churn. |
The motivation was to avoid depending an implementation alignment assumption, i.e. the array data is 8-byte aligned. I was hoping the reduced IL size might bring a benefit from improved inlining, but |
@EgorBo I was surprised that the misses inlining a 19-byte method consisting of an allocation and two intrinsics. |
#91176 (comment) |
AFAIR it's just an implementation detail of CoreCLR. |
The array data is not 8-byte aligned on 32-bit platforms, and there is a risk of alignment fault on arm. We seem to be lucky that the JIT does not generate code that would hit the alignment fault - #20729 has some discussion about it. It is a fragile assumption. It may be possible to trick the JIT into generating code that would hit the alignment fault on Arm32. |
Does adding a call reduce the size here? |
It does reduce IL size by one byte. Saving one byte of IL size is not something we care about. |
BitConverter.GetBytes
Unsafe.WriteUnaligned
in BitConverter.GetBytes
The |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
sharplab
Added
AggressiveInlining
to prevent regressions from from failure to inline.