-
Notifications
You must be signed in to change notification settings - Fork 5.3k
JIT: fix retyping issue in object stack allocation #123743
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
base: main
Are you sure you want to change the base?
Conversation
In cases where we stack allocated an object referred to by local structs, and one of these struct locals was stored to under the value side of a comma, the object allocation phase would inadvertently try and retype the comma, and this retyping ended up cascading back down onto the store and retyping it as well. To fix this, do not run ancestor type propagation for struct stores. Closes dotnet#123718
|
PTAL @jakobbotsch |
|
The behavior of |
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.
Pull request overview
Fixes a JIT object stack allocation retyping bug where ancestor type propagation could retype a GT_COMMA and inadvertently cascade the type change down to a struct store, producing illegal IR.
Changes:
- Skips ancestor type propagation when visiting local struct store nodes during
ObjectAllocator::RewriteUses.
|
Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/jit-contrib |
|
Odd, SPMI passed locally for me. Ah, the failure is in the baseline jit... |
In cases where we stack allocated an object referred to by local structs, and one of these struct locals was stored to under the value side of a comma, the object allocation phase would inadvertently try and retype the comma, and this retyping ended up cascading back down onto the store and retyping it as well.
To fix this, do not run ancestor type propagation for struct stores.
Closes #123718