-
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
JIT: don't forward sub a volatile read tree via copy #62224
JIT: don't forward sub a volatile read tree via copy #62224
Conversation
The copy may not get the same value as the original. Closes dotnet#62048.
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsThe copy may not get the same value as the original. Closes #62048.
|
Some small regressions. Suspect many of the task related ones would not be there in a release SPC. Many could be avoided if we were smarter about when we could move the tree rather than copy (say there's some unrelated statement between the volatile load relop and the jump). But we don't do enough analysis right now to prove this is safe. aspnet.run.windows.x64.checked.mch:
Detail diffs
benchmarks.run.windows.x64.checked.mch:
Detail diffs
coreclr_tests.pmi.windows.x64.checked.mch:
Detail diffs
libraries.crossgen2.windows.x64.checked.mch:
Detail diffs
libraries.pmi.windows.x64.checked.mch:
Detail diffs
libraries_tests.pmi.windows.x64.checked.mch:
Detail diffs
|
cc @dotnet/jit-contrib |
Not sure this is the best way to check for a volatile read tree -- seems like we might want to propagate this upwards or (as noted in the comment) be able to pull this fact out of the VN somehow. |
// Note the candidateTree's result may still be live. | ||
// | ||
// We should only duplicate candidateTree tree if we're sure the copy | ||
// will produce the same result. In particular if the tree contains | ||
// volatile reads, it may not evaluate the same. | ||
// | ||
// Volatile reads are modelled as side effects in VN but not in the IR. |
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.
I assume checking for GTF_ORDER_SIDEEFF
resulted in too many (avoidable) regressions?
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.
Good question, let me check -- doing that would be simpler.
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.
That seems to work out just as well, so will update.
The copy may not get the same value as the original.
Closes #62048.