JIT: prefer edge counts; keep class profiles even if tossing counts #85406
Conversation
If there are both edge and block counts for a method, prefer to use the edge counts (block counts are no longer the default, so are more likely to be stale). Sometimes we decide not to use count data because of correlation or solver issues. When this happens, keep the class profile data viable and let the code that deals with class profiles handle the possibility of stale or mismatched data. Addresses some aspects of dotnet#84446, though it's still not clear why we see static profiles with both block and edge counts.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
@EgorBo PTAL |
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsIf there are both edge and block counts for a method, prefer to use the edge counts (block counts are no longer the default, so are more likely to be stale). Sometimes we decide not to use count data because of correlation or solver issues. When this happens, keep the class profile data viable and let the code that deals with class profiles handle the possibility of stale or mismatched data. Addresses some aspects of #84446, though it's still not clear why we see static profiles with both block and edge counts.
|
| } | ||
| else if (haveEdgeCounts) | ||
| else if (haveBlockCounts) |
There was a problem hiding this comment.
Would this be safer to also handle the haveBlockCounts path if the dataIsGood returned from fgIncorporateEdgeCounts() was false? That way we would prefer the edge counts, but if they were not incorporable, then we would try using the block counts if we have them...
bool dataIsGood = false;
if (haveEdgeCounts)
{
dataIsGood = fgIncorporateEdgeCounts();
}
if (!dataIsGood && haveBlockCounts)
{
dataIsGood = fgIncorporateBlockCounts();
}or maybe even this?
bool dataIsGood = (haveEdgeCounts && fgIncorporateEdgeCounts()) ||
(haveBlockCounts && fgIncorporateBlockCounts());There was a problem hiding this comment.
That's a reasonable suggestion, but I really don't expect to see block counts anymore, and especially do not expect to see both block and edge counts for the same method -- #80481 enabled edge counts for all cases.
As noted in #84446, for some unknown reason the StandardOptimization.mibc file that comes from data collected by our internal optimization process (which merges profile data from multiple runs of things) had some cases where a method hand both block and edge counts. We are in the process of updating this profile data (see eg #85193); I should check if that's still the case.
|
OSX timeout issues are known. |
ghost
locked as resolved and limited conversation to collaborators
If there are both edge and block counts for a method, prefer to use the edge counts (block counts are no longer the default, so are more likely to be stale).
Sometimes we decide not to use count data because of correlation or solver issues. When this happens, keep the class profile data viable and let the code that deals with class profiles handle the possibility of stale or mismatched data.
Addresses some aspects of #84446, though it's still not clear why we see static profiles with both block and edge counts.