-
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 VN of an ASG involving struct retyping. #42806
Conversation
"reinterpretation\n", | ||
addrChild->AsLclVarCommon()->GetLclNum()); | ||
|
||
varDsc->lvOverlappingFields = true; |
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.
there were no overlapping fields there, the flag was used to mark the local var as "bad" for optimizations.
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.
Reinterpreting a stuct of one type as a struct of a different type, essentially is the same as a C++ union where any and all fields of the structs overlap with each other.
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.
So such as case is always "bad for optimizations"
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.
This is not a C++ union because in this case we copy memory, so we don't address the same bytes using different handles.
What you are talking about in our model is represented as "address exposed" in my understanding.
@@ -6687,7 +6683,16 @@ void Compiler::fgValueNumberBlockAssignment(GenTree* tree) | |||
{ | |||
var_types indType = lclVarTree->TypeGet(); | |||
ValueNum fieldSeqVN = srcAddrFuncApp.m_args[0]; | |||
// It could return a sequence that ends with a pseudo fields that does not make sense for me. |
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.
for some static vars we are getting field seq that ends with a pseudo field, not sure why. It could be another issue.
x86.failure.txt
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 am looking for a better way to handle this.
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.
Pseudo fields are things like the first element of an array
PTAL @briansull, cc @dotnet/jit-contrib |
I am trying to understand some VN principles and can't find documentation, the idea is described in JIT Architecture Plan (2009), but do we have description of the actual implementation? |
These field maps was one of the last things added by Dave Detlefs before he left. |
Fixes #42517, replaces logic from dotnet/coreclr#24482 .
Diffs are small as expected:
x64 crossgen - no diffs;
x64 pmi - +113 (1 improved, 3 regressed);
arm64 crossgen - +8 (1 regressed);
arm64 pmi - +40 (1 improved, 3 regressed);
and similar for x86.
An example diff (from arm64 win pmi):
it looks like this change is valid because if
000084
type was not<StackFrame, 16>
it could confuse VN optimizations. For example, if the type wasNotAStackFrame
and we access its field using an VN fromStackField
we will get the same bug as this PR is fixing.