-
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
Fix wrong copy prop after ASG(promoted LCL_VAR with 1 field, call)
.
#41197
Conversation
ASG(promoted LCL_VAR with 1 field, call)
.ASG(promoted LCL_VAR with 1 field, call)
.
PTAL @AndyAyersMS @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.
Changes LGTM.
You looked into the test failures? I took a quick look and the all seem unrelated.
Can you open a follow-up about potential missing VNs? Or maybe more broadly review all the places where we use lvaInSsa
?
All tests were passing before the last commit (comment only change), so I think |
/backport to release/5.0 |
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/221470846 |
Diffs for the library from #41100 :
diffs in
PEMethodSymbol:get_ExplicitInterfaceImplementations
are the fix, diffs inDeriveParameters
andMakeSubmissionInitialization
are correct, but the base version asm was correct as well (a replacement was wrong but the result was valid).0 diffs in master framework libraries (crossgen), pmi diffs:
The regression in
MethodBodySynthesizer:ConstructFieldLikeEventAccessorBody_Regular
is the result of using an unstable mechanism to choose the copy prop replacement, so additional inserts (because we now add forASG(LCL_VAR, call)
) change one replacement and it was less optimal. Both the base and the diff were producing correct asm.The same for
Microsoft.CodeAnalysis.VisualBasic.dasm - Binder:BindLambdaBody(LambdaSymbol,DiagnosticBag,byref):BoundBlock:this
andLocalRewriter:RewriteWinRtEvent(BoundAddRemoveHandlerStatement,BoundEventAccess,bool):BoundStatement:this
.Example of the copy diff.
in the base we were replacing
000595
withV66
from000033
, in the diff we replace it withV07
from33
becauseV07
andV66
switched the order in the hashtable as a random side-effect from correct handling ofthere.
The BING spmi was showing me 3 diffs but it was actually the same method 3 times and it was generating a bad code before, now it is fixed, not sure why
removeDuplicate
did not delete them (-c 105012, 456212, 449211).The pri1 spmi collection has not found any diffs not caught by PMI.
Fixes #41100, will be ported to RC1.
Thanks Andy for the analysis, the repro test, and the proposed fix.