JIT: profile checking through loop opts #99367
Conversation
Keep profile checks enabled until after we have finished running the loop optmizations (recall this is currently just checking for edge likelihood consistency). Fix various maintenance issues to make this possible. Most are straightforward, but a few are not: * Whenever we create a new BBJ_COND we have to figure out the right likelihoods. If we're copying an existing one (say loop inversion) we currently duplicate the likelihoods. This is a choice, and it may not accurately represent what happends, but we have no better information. * If we invent new branching structures we need to put in reasonable likelihoods. For cloning we assume flowing to the cold loop is unlikely but can happen. Block weights and edge likelihoods are not yet consistent. The plan is to get all the edge likelihoods "correct" and self-consistent, and then start rectifying edge likelihoods and block weights. Contributes to dotnet#93020.
ghost
assigned 
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsKeep profile checks enabled until after we have finished running the loop optmizations (recall this is currently just checking for edge likelihood consistency). Fix various maintenance issues to make this possible. Most are straightforward, but a few are not:
Block weights and edge likelihoods are not yet consistent. The plan is to get all the edge likelihoods "correct" and self-consistent, and then start rectifying edge likelihoods and block weights. Contributes to #93020.
|
|
@amanasifkhalid PTAL It's possible getting past loop opts was the hard part. We'll see. |
|
Would be good to run some extended testing. |
Also seeing some diffs, which is a bit unexpected; didn't think anything relied on likelihoods yet |
| // TODO: this is a bit of out sync with what we do for block weights. | ||
| // Reconcile. | ||
| // | ||
| const weight_t fastLikelihood = 0.999; |
There was a problem hiding this comment.
Out of curiosity, where does this number of significant figures come from?
There was a problem hiding this comment.
It's just an arbitrary factor. For most cloned loops we actually never expect the cold loop to run, since we think it's execution may cause exceptions. But setting likelihood to zero seemed to drastic.
There was a problem hiding this comment.
optCloneLoop scales the fast loop blocks by 0.99. There is a comment about it:
runtime/src/coreclr/jit/loopcloning.cpp
Lines 1944 to 1949 in 5f52977
It seems like we should use the same likelihood in both places.
There was a problem hiding this comment.
Ah, good point. I will tweak this in the next round of changes.
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress |
|
Azure Pipelines successfully started running 2 pipeline(s). |
CI diffs are a lot more modest than my local diffs. I will dig into a few and see what's up. |
We mark blocks rare that were not rare before, and this modifies layout and alters allocation. |
Keep profile checks enabled until after we have finished running the loop optmizations (recall this is currently just checking for edge likelihood consistency).
Fix various maintenance issues to make this possible. Most are straightforward, but a few are not:
Block weights and edge likelihoods are not yet consistent. The plan is to get all the edge likelihoods "correct" and self-consistent, and then start rectifying edge likelihoods and block weights.
Contributes to #93020.
Diffs