JIT: Remove bbFallsThrough check in optFindLoopCompactionInsertionPoint

[amanasifkhalid]

Calling bbFallsThrough isn't all that helpful here, as it doesn't consider BBJ_ALWAYS blocks to the next block, BBJ_COND blocks that don't fall through for the false path, etc. I'm planning on getting rid of bbFallsThrough everywhere except in fgReorderBlocks (that removal will hopefully come when we replace our block layout algorithm altogether), but to still be able to short-circuit optFindLoopCompactionInsertionPoint, I added some manual checks for blocks that can "fall through."

cc @dotnet/jit-contrib, @jakobbotsch PTAL. The diffs weren't that big locally, but I'm open to different/more radical approaches here. Thanks!

[dotnet-policy-service]

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

[amanasifkhalid]

Diffs

[AndyAyersMS]

The more radical thing would be to stop doing loop compaction entirely. Now that we have a flow-based approach to finding loops, it should not matter what other blocks might appear between the lexically first and lexically last loop blocks.

Whether we can "fix" this later though is likely the big question. Once we get to layout we will want to make loop bodies compact.

[amanasifkhalid]

The more radical thing would be to stop doing loop compaction entirely.

I tried this locally out of curiosity, and the size/PerfScore regressions suggest our current layout algorithm doesn't handle uncompacted loops all that well. I've added a note to #93020 to consider skipping loop compaction once have a new layout algorithm, assuming the new algorithm does a decent job of placing loop bodies' blocks contiguously -- if we start with a RPO traversal, I guess that would negate the need for compaction?

[AndyAyersMS]

if we start with a RPO traversal, I guess that would negate the need for compaction?

I believe that's the case, yes.

[jakobbotsch]

I don't think RPO will guarantee compactness of natural loops -- for example, the RPO can have outside-loop successors of the exiting blocks between the header and its inside-loop successors.

[jakobbotsch]

Seems fine to me. I hope long term we remove the compaction entirely in favor of the block layout in the backend.