[release/8.0-staging] JIT: fix issue with out of order importer spilling around some calls #95587
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #95539 to release/8.0-staging
/cc @AndyAyersMS
Customer Impact
Issue #95394 was opened by a customer.
An application that contains a certain pattern of code may compute with the wrong values, or crash. The pattern is one where there is a copy of a local struct on the (IL) stack, then a virtual, interface, or delegate call that modifies that same local, and then a use of the copy after the call. In the repro case (here
P.XYis virtual):In such cases if the call is optimized by GDV (Guarded Devitualization)—as it is likely to be now that PGO is enabled by default in .NET 8—the subsequent read of
tupleTempmay actually read the values of thetuplereturned by the call, instead of the values thattuplehad before the call. So, in the example above,fends up with the wrong value.The underlying bug in the JIT is pre-existing and goes back to at least .NET 6.0.
Whether or not the IL stack contains the problematic sequence depends on the options passed to
csc, in particular the default options in release mode will encouragecscto rely more heavily on the stack.Testing
Verified the fix on several version of the originally reported repro case.
Ran standard CI testing, plus additional PGO, outerloop, and jitstress. Fix did not lead to any diffs on SPMI collections.
Risk
Low.
A similar fix was made for boxes and GDV calls in #60355.
In the jit there are several factors that contribute to this being a tricky area:
The fix here is to move the spill to the proper place immediately after it is created, so that the JIT no longer produces a temporarily out of order IR sequence.