JIT: better support for patchpoints in try regions

[AndyAyersMS]

This change adds control flow to ensure that an OSR method for a patchpoint
nested in try regions enters those regions try from the first block of each
try rather than mid-try.

This lets these OSR methods conform to the data flow expectations that the
only way control flow can enter a try is via its first block.

See #33658 for more details on the approach taken here.

Fixes#35687.

[ghost]

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

Issue Details

---

This change adds control flow to ensure that an OSR method for a patchpoint
nested in try regions enters those regions try from the first block of each
try rather than mid-try.

This lets these OSR methods conform to the data flow expectations that the
only way control flow can enter a try is via its first block.

See #33658 for more details on the approach taken here.

Fixes #35687.

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

[AndyAyersMS]

It might be possible to merge this new logic with the try region trimming done in fgRemoveEmptyBlocks but for now I'm keeping it separate.

No diffs outside of OSR (which we currently can't easily diff; seems like I should do an SPMI collection here perhaps).

cc @dotnet/jit-contrib

[BruceForstall]

1. I think you should add some of the comment from #33658 (comment) into your new code, especially the pseudo-code of the flow you are creating.
2. It's pretty weird that a function named fgRemoveEmptyBlocks can create a bunch of blocks and flow and a new temp.
3. Re (2), it looks like fgRemoveEmptyBlocks gets called on inlinees, and then later in morph init. I guess that ends up not creating multiple flow because we don't inline functions with EH, but it maybe creates an impediment if we ever do (and the inlinee is an OSR method? So, maybe not a problem?)

[AndyAyersMS]

Going to wait on this until #59789 lands so (hopefully) I can get clean OSR runs.

[AndyAyersMS]

Yeah, fgRemoveEmptyBlocks should probably be renamed, maybe fgUpdateFlowAfterImportation ...? Similar in nature to fgAddInternal too, though that runs a bit later on.

As for running it on inlinees, right, only the first bit (removing un-imported blocks) will matter today.

We'll never inline OSR methods, they never get called in a normal fashion.

[AndyAyersMS]

Merged in the other OSR fix, so will try running the experimental pipeline here. Don't expect it to be green as there is a latent crossgen2 issue.

[AndyAyersMS]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

Looks like a number of novel failures, so I'll have to revise this PR.

[AndyAyersMS]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

Still have one overly aggressive assert (mutual protect case)... the OSR entry can be in a nested try and still not need step blocks.

[AndyAyersMS]

/azp run runtime-jit-experimental

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

jit-experimental now has just the expected set of failures.

[AndyAyersMS]

@BruceForstall feel free to take another look; think I addressed your comments.

[BruceForstall]

LGTM. Thanks for adding the detailed comments.