JIT: Cache memory dependencies for VN map selects #89241
Conversation
Hoisting relies on being able to look at which memory dependencies a candidate is dependent upon. VN tracks these during the map select logic; however, it fails to do so when the map selection hits the cache. This changes the logic to make sure the memory dependencies are cached. Fix dotnet#75442
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsHoisting relies on being able to look at which memory definitions a candidate is dependent upon. VN tracks these during the map select logic; however, it fails to do so when the map selection hits the cache. This changes the logic to make sure the memory dependencies are cached. Fix #75442 TP impact of the "obvious" approach was not as bad as I expected; below 0.1%. Diff of memory stats over win-x64 aspnet. This costs about 1% more ValueNumber memory, which amounts to about 0.09% more overall memory usage. Note: this is best reviewed with whitespace diffs turned off as I have unnested some code in
|
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS No diffs. Some minor TP regressions (up to +0,07%). Memory regressions can be seen above. |
Hoisting relies on being able to look at which memory definitions a candidate is dependent upon. VN tracks these during the map select logic; however, it fails to do so when the map selection hits the cache. This changes the logic to make sure the memory dependencies are cached.
Fix #75442
TP impact of the "obvious" approach was not as bad as I expected; below 0.1%.
Diff of memory stats over win-x64 aspnet. This costs about 1% more ValueNumber memory, which amounts to about 0.09% more overall memory usage.
Note: this is best reviewed with whitespace diffs turned off as I have unnested some code in
VNForMapSelectWork.