JIT: Use likelihood-based edge weights #99736
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@AndyAyersMS lots of diffs, but they aren't as big as I expected... There are some late phases where I don't use likely weights due to likelihoods not being propagated yet, so I'll leave this as a draft for now. I'm going to start working on ensuring successor block weights are updated as edges are created/removed/redirected. |
src/coreclr/jit/fgbasic.cpp
Outdated
| { | ||
| jmpBlk->bbWeight = BB_ZERO_WEIGHT; | ||
| } | ||
| jmpBlk->bbWeight = newEdge->getLikelyWeight(); |
There was a problem hiding this comment.
You can use setBBProfileWeight here
|
@AndyAyersMS thanks for taking a look! I think the diffs aren't as good as they could be due to unreliable block weights, and I'm assuming fixing that will require a process similar to the edge likelihoods work. I'm curious if you're planning on taking this change with potentially subpar diffs for now? |
|
@AndyAyersMS updated diffs still show lots of regressions. I suppose we could leave this open and work on improving block weights first to see if that fixes some of the regressions, or we could merge this, and then it'll be easier to determine if profile maintenance work improves diffs locally -- up to you. |
|
Probably worth another update, now that repairs are there? |
I was planning on opening a draft PR for running profile repair right before layout (the diffs were quite dramatic locally), though it might make sense to skip a step and try that here, in conjunction with using likelihood-based edge weights during layout. Would you like me to try that here? |
|
In the diffs, I'm still seeing about an equal number of size improvements and regressions on x64, and generally more improvements than regressions on arm64 (probably due to the differences in jump sizes between architectures). Looking at the example regressions on Windows x64, it looks like with likelihood-based edge weights, we're doing a better job of moving cold blocks towards the end of the method, such that the block weights/PerfScores are in descending order -- this results in less fall-through, but if these blocks are truly cold, maybe it's worth the tradeoff? |
|
SPMI failures look like #101070. |
| // A takenRatio of 0.50 means taken 50% of the time, not taken 50% of the time | ||
| // A takenRatio of 0.90 means taken 90% of the time, not taken 10% of the time | ||
| // | ||
| double takenCount = edgeToDest->getLikelyWeight(); |
There was a problem hiding this comment.
We should revise this to just use likelihoods, instead of weights? But we can do this as a follow-up.
| // | ||
| // Returns: | ||
| // Suitable phase status | ||
| // | ||
| PhaseStatus Compiler::fgComputeBlockAndEdgeWeights() | ||
| PhaseStatus Compiler::fgComputeBlockWeights() |
There was a problem hiding this comment.
This phase should eventually go away. We can compute fgCalledCount much earlier now. But let's leave that for follow-up too.
There was a problem hiding this comment.
Are you suggesting we compute fgCalledCount in fgIncorporateProfileData? And would we still want to call fgComputeMissingBlockWeights? I tried removing this phase altogether locally and computing fgCalledCount during profile incorporation, and the diffs from this are quite big
There was a problem hiding this comment.
More or less -- but both may still be needed for non-pgo cases?
We are going to need to find the right reconciliation between having PGO and not having it. Ideally perhaps we just always think we have it, but I don't know if we want to pay the costs of this in modes like minopt where we probably don't ever look at the data...
|
@AndyAyersMS Thanks for the review! |
Part of dotnet#93020. Removes FlowEdge::m_edgeWeightMin and FlowEdge::m_edgeWeightMax, and relies on block weights and edge likelihoods to determine edge weights via FlowEdge::getLikelyWeight.
Part of #93020. Removes
FlowEdge::m_edgeWeightMinandFlowEdge::m_edgeWeightMax, and relies on block weights and edge likelihoods to determine edge weights viaFlowEdge::getLikelyWeight.I'm opening this now so the diffs are visible.