JIT: Move targets of hot jumps to create fallthrough post-RPO layout #102927
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
Seems like k-opt is going to need more bake time, so let's focus on getting this merged for now. |
Sounds like a plan; I think this is ready for review. TP cost isn't nothing, but I think we're still in the green relative to the cost of the old layout. |
There are some substantial code size increases -- is this because we're more aggressively moving cold code now? |
I think that's part of it -- since the threshold for what counts as cold code is now slightly more liberal, there are probably more instances where we don't move a block's target up, and instead move it to the cold section in |
As long as the hot code density improves it should be ok to have somewhat more code overall. Hot/cold splitting would have a similar effect. |
|
SPMI failure is timeout. |
|
Regressions: |
After establishing an RPO-based layout, we currently try to move any backward jumps up to their successors, if it is profitable to do so in spite of any fallthrough behavior lost. In #102763, we see many instances where the RPO layout fails to create fallthrough for forward jumps on the hot path, such as in cases where a block is reachable from many predecessors. This work addresses the RPO's limitations by also considering moving the targets of forward jumps (conditional and unconditional) to maximize fallthrough.
cc @dotnet/jit-contrib -- parsing the diffs of this is tedious, so check out `#102763 for some example changes in block layout. Thanks!