-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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 the latest base register while accessing the stack #38834
Conversation
This reverts commit d39af7084687e8fe5e6d4f71674ec84d36a88340.
This reverts commit 311fd81.
@dotnet/jit-contrib |
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.
The changes seem reasonable, but I would probably have used a return value for the base register (since these methods are currently void
) rather than adding a pointer as an "out" parameter.
Thanks @CarolEidt . My first thought was to return a value but since it was one of the |
To me, the inconsistency actually makes it clearer that these methods are "special", though I supposed there's also the danger that the caller will ignore the return value, since C++ makes it easy to do so. Do others have different opinions? @dotnet/jit-contrib |
I would just go with return type = void and returning the base register via out parameter (that should be named pBaseReg) |
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! |
When we try to access a field of a struct parameter, we calculate the offset of field using wrong base register. The struct that is getting accessed has 257 fields and we use
sp
as a base register to calculate the offset. However at 152nd field we reach the encoding limit of0xFF8
and hence decide to usefp
as a new base register to calculate the offset from. But we don't take the new base register into account when calculating the final indirect of the field.Here is the snippet of code that loads each field .
The fix is to use the latest base register we find out (through
lvaFrameAddress
) insideemitIns_R_S()
when called withINS_movw
and propagate it viaemitIns_genStackOffset()
. In order to come up with a small repro case, I wanted to see how this situation arises with stress flags, but couldn't find exact reason. One thing that I noticed was in repro case, thecompLclFrameSize
is lot bigger than the non-repro case, but again was not sure enough.I ran various jitstress pipelines and looks like the
mcc_i*
tests are passing. Here is the test log.Fixes: #35501 and #36199