JIT: Consolidate layout passes into one phase

[amanasifkhalid]

Part of #107749. This replaces our RPO layout and cold code motion phases with a single loop-aware RPO computation (with cold blocks ignored) that we feed into 3-opt as its initial layout. This has the nice property of needing to reorder the block list only once, and never leaving it in a temporarily invalid state (i.e. with EH regions broken up).

My initial plan was for this PR to be zero-diff since I split out all the invariant changes (like not reordering cold/handler blocks at all) into separate PRs, but I found it necessary to implement moving try regions around to avoid regressing layout quality. Suppose we have some initial layout that looks like this:

[BB01 (hot)]
[BB02 (cold)]
[BB03 (hot, try entry)]
[BB04 (hot, try exit)]
[BB05 (hot)]

When reordering the block list, we want to only reorder within try regions to avoid breaking their contiguity. Suppose 3-opt wants the block list to look like BB01 -> BB03 -> BB04 -> BB05 -> BB02. If we only reorder within regions, we cannot place BB03 after BB01, so the layout remains as-is, with the cold block inline. And if BB05 were somewhere else in the initial layout, we wouldn't be able to move it after BB04 because they're in different regions.

We can be a bit clever and remember the last hot block in each region, so that EH region boundaries don't trip us up. However, this only enables better movement within regions, and nested regions end up sinking down the method. We end up with the following layout:

[BB01 (hot)]
[BB05 (hot)]
[BB02 (cold)]
[BB03 (hot, try entry)]
[BB04 (hot, try exit)]

The hot part of the main method body is compact, but the try region is interleaved with cold code. After adding support for try region movement, we can now move try regions up to their ideal successors, when doing so doesn't break EH nesting invariants:

[BB01 (hot)]
[BB03 (hot, try entry)]
[BB04 (hot, try exit)]
[BB05 (hot)]
[BB02 (cold)]

Thus, this change has some churn, but it looks mostly like a PerfScore win.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[amanasifkhalid]

/azp run runtime-coreclr libraries-jitstress, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[amanasifkhalid]

/azp run runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[amanasifkhalid]

/azp run runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[amanasifkhalid]

/azp run runtime-coreclr libraries-jitstress, runtime-coreclr libraries-pgo

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

[amanasifkhalid]

I decided to repurpose bbPreorderNum for the ordinal instead of bbPostorderNum, since we can modify the former during the loop-aware RPO computation without breaking it. I probably should've split this out into a separate PR, though I've created enough review burden with this work as-is.

[amanasifkhalid]

This code isn't anything new. Since we no longer need to move cold EH blocks back in line after layout, we can bring back the EH repair logic I introduced in #108634. But now that we don't reorder handler regions, I've simplified this code to only reset try region entries in the main method body.

[amanasifkhalid]

I forgot to check if the unlikely target is in the candidate span of blocks before checking its ordinal. This isn't a correctness issue per se, but switching ordinals from bbPostorderNum to bbPreorderNum created churn here.

[amanasifkhalid]

I can probably do something cheaper than potentially iterating the whole main method body here, though this path seems cold enough to not noticeably affect TP diffs. I'll try something in a follow-up and see if it's worth it.

[amanasifkhalid]

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs look like a PerfScore improvement overall, except for in coreclr_tests and sometimes libraries_tests. We're getting a little bit of TP back, but I think there's further room for improvement by templating away some of the hot EH-specific checks. Thanks!