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
OSR gets wrong offset for memory arg on arm64 OSX #68194
Comments
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsRunning libraries pgo w/osr "stress", arm64 OSX (trying to verify fix for #68170) I hit a different error.
Note
Looks like the issue goes back at least to the Tier0 patchpoint info creation.
However Tier0 codegen gets this right, and it's based on the same information. So not clear yet what is going wrong.
|
Ah, the issue is that the low bit of the offset in the patchpoint info is used to track exposure info, so any local with and odd offset is going to get the wrong value. That made sense for x64 and most arm64, but on OSX the ABI variances make it possible for args to be at odd offsets. Will need to revise how this information is stored. runtime/src/coreclr/inc/patchpointinfo.h Lines 157 to 161 in 544f720
runtime/src/coreclr/inc/patchpointinfo.h Lines 182 to 185 in 544f720
|
We can now have Tier0 locals at byte offsets, so rework how the offset information is incoded in patchpoints to make this possible. Closes dotnet#68194.
We can now have Tier0 locals at byte offsets, so rework how the offset information is incoded in patchpoints to make this possible. Closes #68194.
We can now have Tier0 locals at byte offsets, so rework how the offset information is incoded in patchpoints to make this possible. Closes dotnet#68194.
Running libraries pgo w/osr "stress", arm64 OSX (trying to verify fix for #68170) I hit a different error.
Isolated this to OSR codegen for
DynamicMethod:Init
.Note
arg8
andarg9
have the same offset in the OSR disasm below (and likewise in the codegen)Looks like the issue goes back at least to the Tier0 patchpoint info creation.
However Tier0 codegen gets this right, and it's based on the same information. So not clear yet what is going wrong.
The text was updated successfully, but these errors were encountered: