JIT: Clean up 3-opt driver logic #112210
JIT: Clean up 3-opt driver logic #112210
Conversation
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| // True if we reordered anything, false otherwise | ||
| // | ||
| bool Compiler::ThreeOptLayout::RunThreeOptPass() | ||
| bool Compiler::ThreeOptLayout::RunThreeOpt() |
There was a problem hiding this comment.
Here's what I want the hierarchy of 3-opt methods to look like:
ThreeOptLayout::Run: Set up some data structures, run 3-opt, and reorder the block listThreeOptLayout::RunThreeOpt: Run a 3-opt pass, and evaluate the new layout cost. TODO: If we want to try searching for a better local optimum, run another 3-opt pass with a different initial layout. I'd be surprised if this second pass makes a difference when we don't have loops, so a decent starting heuristic is to run another pass only when we have them. My current plan is to first run 3-opt withoutfgMoveHotJumpsrun on the initial layout, and then if we have loops, runfgMoveHotJumpson the initial layout, and try 3-opt again. We'll keep the better of the two.ThreeOptLayout::RunGreedyThreeOptPass: Actually run 3-opt until convergence on whatever initial layout we're given.
There was a problem hiding this comment.
We'll keep the better of the two.
As we saw with the fgMoveHotJumps data, layout score better doesn't reflect everything we care about... any thoughts on how we might also assess the compactness of a layout?
There was a problem hiding this comment.
Since this computation would only happen twice per compilation, I think we can implement a more sophisticated cost model using one of the techniques you mentioned in #112016 just for comparing candidate layouts, without it being too expensive. If we can't do that, then assuming 3-opt converges to the same cost with and without fgMoveHotJumps, we could break ties by choosing the layout with fgMoveHotJumps under the assumption that it's more compact.
|
@dotnet/jit-contrib PTAL. No diffs. Thanks! |
2 participants
Follow-up to #111989. Now that we only run one pass of 3-opt, we can remove some cruft needed to maintain state across 3-opt passes. This is a meek attempt to reduce the size of #112004 by separating out some of the no-diff changes.