JIT: better support for patchpoints in try regions #59784
Conversation
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 dotnet#33658 for more details on the approach taken here. Fixes dotnet#35687.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsThis change adds control flow to ensure that an OSR method for a patchpoint This lets these OSR methods conform to the data flow expectations that the See #33658 for more details on the approach taken here. Fixes #35687.
|
|
It might be possible to merge this new logic with the try region trimming done in 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 |
There was a problem hiding this comment.
- I think you should add some of the comment from On Stack Replacement Next Steps #33658 (comment) into your new code, especially the pseudo-code of the flow you are creating.
- It's pretty weird that a function named
fgRemoveEmptyBlockscan create a bunch of blocks and flow and a new temp. - Re (2), it looks like
fgRemoveEmptyBlocksgets 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?)
|
Going to wait on this until #59789 lands so (hopefully) I can get clean OSR runs. |
|
Yeah, 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. |
|
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. |
|
/azp run runtime-jit-experimental |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Looks like a number of novel failures, so I'll have to revise this PR. |
|
/azp run runtime-jit-experimental |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Still have one overly aggressive assert (mutual protect case)... the OSR entry can be in a nested try and still not need step blocks. |
|
/azp run runtime-jit-experimental |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
jit-experimental now has just the expected set of failures. |
|
@BruceForstall feel free to take another look; think I addressed your comments. |
ghost
locked as resolved and limited conversation to collaborators
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.