Extraction of non-loop blocks during loop recognition uses questionable condition

[BruceForstall]

As discussed here, there is a check in MakeCompactAndFindExits that seems questionable, at best:

runtime/src/coreclr/jit/optimizer.cpp

Line 2124 in 66da2e5

if (!BasicBlock::sameEHRegion(previous, nextLoopBlock) || !BasicBlock::sameEHRegion(previous, moveAfter))

It tries to avoid creating illegal EH regions by preventing moving blocks. But it doesn't properly handle region adjacency where moving a range of blocks is legal. E.g., a range abutting a try begin.

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

Issue Details

---

As discussed here, there is a check in MakeCompactAndFindExits that seems questionable, at best:

runtime/src/coreclr/jit/optimizer.cpp

Line 2124 in 66da2e5

if (!BasicBlock::sameEHRegion(previous, nextLoopBlock) || !BasicBlock::sameEHRegion(previous, moveAfter))

It tries to avoid creating illegal EH regions by preventing moving blocks. But it doesn't properly handle region adjacency where moving a range of blocks is legal. E.g., a range abutting a try begin.

Author:	BruceForstall
Assignees:	BruceForstall
Labels:	area-CodeGen-coreclr
Milestone:	Future

[AndyAyersMS]

As of #96995 this method no longer exists, but optCompactLoop has a similar check (not clear if it has the same issue or not)

runtime/src/coreclr/jit/optimizer.cpp

Line 2843 in d7e85d9

if (!BasicBlock::sameEHRegion(previous, nextLoopBlock) || !BasicBlock::sameEHRegion(previous, insertionPoint))