JIT: rework logic for when OSR imports method entry #63406
Conversation
OSR wasn't aggressive enough in importing the original method entry, so if an inlinee introduced a recursive tail call that we wanted to turn into a loop, we might find that the target block for the loop branch never got created. Update the logic so that we import the entry if we're in the root method and we have an inlineable call in tail position. This will over-import in many cases but if those blocks turn out to be unreachable they will usually be removed without impacting final code gen. Fixes one of the OSR stress mode failures seen in dotnet#62980.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsOSR wasn't aggressive enough in importing the original method entry, Update the logic so that we import the entry if we're in the root Fixes one of the OSR stress mode failures seen in #62980.
|
|
cc @dotnet/jit-contrib We don't have a lot of OSR SPMI instances. Locally this lead to 3 minor diffs. |
|
@dotnet/jit-contrib ping - need this fix as part of enabling OSR by default. |
|
@dotnet/jit-contrib still need someone to look at this -- it is mostly moving checking a bit later and (for OSR) making it a bit more aggressive at importing the original method's entry. |
ghost
locked as resolved and limited conversation to collaborators
OSR wasn't aggressive enough in importing the original method entry,
so if an inlinee introduced a recursive tail call that we wanted to
turn into a loop, we might find that the target block for the loop
branch never got created.
Update the logic so that we import the entry if we're in the root
method and we have an inlineable call in tail position. This will
over-import in many cases but if those blocks turn out to be unreachable
they will usually be removed without impacting final code gen.
Fixes one of the OSR stress mode failures seen in #62980.