Repository navigation
Improve fgValueNumberBlockAssignment - #64110
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT Issue Details
Finally, this change unifies the code common to numbering We're expecting some positive diffs from the aforementioned more precise numbering. Part of #58312.
|
9e517e2 to
8ae2536
Compare
fgValueNumberBlockAssignmentfgValueNumberBlockAssignment
|
@dotnet/jit-contrib |
"fgValueNumberBlockAssignment" had a very interesting oddity: it re-VNs the source tree of the assignment. This is unnecessary, and is in fact a pessimization, as it means we will fail to VN assignments from sources it does not understand. This change fixes that, bringing along some positive diffs from numbering stores from field indirections. "fgValueNumberBlockAssignment" also needs to maintaint the invariant that a location's VN will always match its type. It was failing to do that in cases where the assignment's source was not local. This change fixes that. Finally, this change unifies the code common to numbering "CopyBlk" and "InitBlk" cases. There is no need for them to be different.
8ae2536 to
4601ecc
Compare
|
/azp run Antigen, Fuzzlyn |
|
Azure Pipelines successfully started running 2 pipeline(s). |
fgValueNumberBlockAssignmenthad a very interesting oddity: it re-VNd the source tree of the assignment. This is unnecessary, and is in fact a pessimization, as it means we will fail to VN assignments from sources it does not understand. This change fixes that, bringing along some positive diffs from numbering stores from field indirections.fgValueNumberBlockAssignmentalso needs to maintain the invariant that a location's VN will always match its type.It was failing to do that in cases where the assignment's source was not local. This change fixes that.
Finally, this change unifies the code common to numbering
CopyBlkandInitBlkcases. There is no need for them to be different.Some positive diffs from the aforementioned more precise numbering.
Part of #58312.