JIT: Add 3-opt implementation for improving upon RPO-based layout #103450
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
| improvedLayout = false; | ||
| BasicBlock* const exitBlock = blockVector[blockCount - 1]; | ||
|
|
||
| for (unsigned i = 1; i < (blockCount - 1); i++) |
There was a problem hiding this comment.
I think the root of the TP cost is here -- we want to avoid having to search for possible cut points.
One approach is to just pick randomly, but I think we can do better for now. Roughly speaking in the pass above we should find all blocks that are either not just before their optimal successor and/or not just after their optimal successor.
We can rank these by the difference in the current vs optimal score. Then greedily pick the worst, that gives the first cut point. For the second cut point you can pick the best pred for the first cut point's current next block, or the best succ for the current pred of the first cut point's ideal successor. That is, if we have
S ~~~~ 1|2 ~~~ 3|4 ~~~ 5|6 ~~~ E
1's ideal succ is 4
reordering is
S ~~~~ 1|4 ~~~ 5|2 ~~~ 3|6 ~~~ E
So we either try and find a 5 which is the ideal pred of 2, or a 6 which is the ideal succ of 3.
Failing that we might pick some other block that is not currently followed by its ideal succ.
So one idea is to keep 3 values for each block: its min score, current score, and best score (lower is better). Order the blocks by current-min. Pick of the best as the first split, and then see if any of the next few provide a good second split.
Likely though this ends up needing a priority queue or similar as once we accept an arrangement we need to update some of the costings...
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
No description provided.