Explicitly represent BBJ_EHFINALLYRET successors

[BruceForstall]

Currently, BBJ_EHFINALLYRET blocks have no explicit successors in the IR. To implement successor iteration, a very expensive process is followed to (1) find the region of blocks where a BBJ_CALLFINALLY block calling the finally might be found, (2) search the region for such blocks, and (3) return as a successor all the BBJ_ALWAYS blocks in the corresponding BBJ_CALLFINALLY/BBJ_ALWAYS pair.

Change the IR to explicitly represent and maintain this list of successors for BBJ_EHFINALLYRET blocks. The representation is a simple array of BasicBlock*, similar to how BBJ_SWITCH block targets are represented.

Fixes#84278

Notes:

1. The BBJ_EHFINALLYRET successors are computed in impFixPredLists(). There are various dumpers that run before this, so we need to tolerate incomplete successor information in some places.
2. ehGetCallFinallyBlockRange() is still used by some code. I changed the semantics to return a [first..last] range inclusive of last instead of the previous [beginning..end) range exclusive of end. This makes it easier to use with our BasicBlock iterators.

[ghost]

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

Issue Details

---

Currently, BBJ_EHFINALLYRET blocks have no explicit successors in the IR. To implement successor iteration, a very expensive process is followed to (1) find the region of blocks where a BBJ_CALLFINALLY block calling the finally might be found, (2) search the region for such blocks, and (3) return as a successor all the BBJ_ALWAYS blocks in the corresponding BBJ_CALLFINALLY/BBJ_ALWAYS pair.

Change the IR to explicitly represent and maintain this list of successors for BBJ_EHFINALLYRET blocks. The representation is a simple array of BasicBlock*, similar to how BBJ_SWITCH block targets are represented.

Fixes #84278

Notes:

1. The BBJ_EHFINALLYRET successors are computed in impFixPredLists(). There are various dumpers that run before this, so we need to tolerate incomplete successor information in some places.
2. ehGetCallFinallyBlockRange() is still used by some code. I changed the semantics to return a [first..last] range inclusive of last instead of the previous [beginning..end) range exclusive of end. This makes it easier to use with our BasicBlock iterators.

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

[BruceForstall]

No diffs, generally a slight TP improvement, in some cases significant.

[BruceForstall]

@AndyAyersMS PTAL
cc @dotnet/jit-contrib

[AndyAyersMS]

Looks good overall. Left a few suggestions for possibly simplifying the code.

[BruceForstall]

@AndyAyersMS I addressed your suggestions.

[BruceForstall]

The superpmi-diffs failure is out of disk space.
The test failures are Quic (known) and 4 win-arm64 failures. Oddly, the exact same 4 failures were reported by a release/7.0 PR today: #93424. I can't repro the failures locally either with my change, without it, or with a fresh build of HEAD of runtime/main.

[BruceForstall]

Looks like @AndyAyersMS had a PR with the same win-arm64 failures: #93371

[BruceForstall]

Oddly, the exact same 4 failures were reported by a release/7.0 PR

Maybe the build machines picked up a new MSVC arm64 compiler that has a bug? It does look like the compiler changed recently.