JIT: Simplify block insertion logic during loop compaction

[amanasifkhalid]

Similar to #107371, don't worry about breaking up fallthrough when moving non-loop blocks out of loop bodies. We can rely on block layout to restore any fallthrough behavior worth keeping.

I expect this will incur diffs from optSetBlockWeights, since it still relies on the lexical ordering of blocks.

[dotnet-policy-service]

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

[amanasifkhalid]

Small diffs as expected; odd that TP didn't improve. I'm guessing we don't need to compact loops all that often, so pre-computing insertionPoint is often wasted.

[amanasifkhalid]

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Thanks!

[AndyAyersMS]

Ultimately, we should not need to compact loops at all.

But that may be too radical a change to make right now.

[amanasifkhalid]

Ultimately, we should not need to compact loops at all.

Yeah, once we replace optSetBlockWeights with something graph-based, I think it'll be easier to get rid of loop compaction. I'll give it a try once we're at that point.

[AndyAyersMS]

Which reminds me -- I wonder if we should switch the layout RPO over to something like the "loop aware" RPO-inspired ordering that is now used in VN?

The main distinction being that that RPO may intermingle non-loop blocks with loop blocks, whereas the loop aware ordering takes care to visit all loop blocks before any blocks that may follow.

[AndyAyersMS]

There's not yet a convenient abstraction for this order but it would not be too hard to make one that VN and something else could share.

[amanasifkhalid]

Which reminds me -- I wonder if we should switch the layout RPO over to something like the "loop aware" RPO-inspired ordering that is now used in VN?

Interesting, I wasn't aware of this functionality. I'll take a look at it next. It would be nice if this could render fgMoveHotJumps mostly redundant: Aside from ensuring loops are compact, if the loop-aware RPO also ensures the loop head is at the top of the loop, then I think we shouldn't have to consider back edges in fgMoveHotJumps at all. Instead, fgMoveHotJumps will just be for moving blocks with multiple predecessors up to the hottest one.