JIT: Continue profile consistency checks until after finally cloning #109792
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
cc @dotnet/jit-contrib, @AndyAyersMS PTAL. |
|
/azp run runtime-coreclr libraries-jitstress |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
ping @AndyAyersMS, |
| @@ -673,6 +673,9 @@ unsigned int ObjectAllocator::MorphAllocObjNodeIntoStackAlloc( | |||
| if (predBlock->hasProfileWeight()) | |||
| { | |||
| block->setBBProfileWeight(predBlock->bbWeight); | |||
| JITDUMP("Profile weight into " FMT_BB " needs to be propagated to successors. Profile %s inconsistent.\n", | |||
| block->bbNum, comp->fgPgoConsistent ? "is now" : "was already"); | |||
| comp->fgPgoConsistent = false; | |||
There was a problem hiding this comment.
Ah, I should try harder to fix this one up. With PGO in most cases this path will have zero weight.
There was a problem hiding this comment.
In my experience, this path triggered consistency checks pretty rarely, and I expect that we'll want to run profile repair after the first flowgraph simplification pass for now, so this might trivially fix itself.
Part of #107749. The next few opt phases alter flow substantially, such that we need to propagate new weight throughout the flowgraph. That will probably justify running profile synthesis after, in a later PR.