Allow instrumentation for methods with explicit tail calls #58632
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsI'm not fully sure in this change, but looks like currently we always promote methods with explicit tails to tier1 (and enable opts even in Debug?) so we never instrument them... From my understanding, QJFL=1 (which is 0 by default) ideally implies a working OSR so we should not hit SO here
|
I think the comment is just outdated, we will never hit potential SO anymore since tailcall helpers work in tier-0 as well. EDIT: It should even be ok to always start them out in tier-0 now since we don't optimize recursion to loops in tier0 anyway. |
src/coreclr/jit/fgbasic.cpp
Outdated
| { | ||
| // Method has an explicit tail call that may run like a loop or may not be generated as a tail | ||
| // call in tier 0, switch to optimized to avoid spending too much time running slower code and | ||
| // to avoid stack overflow from recursion | ||
| // call in tier 0, switch to optimized to avoid spending too much time running slower code | ||
| fgSwitchToOptimized(); |
There was a problem hiding this comment.
On second thought it might be a good idea to go back to what you had before -- jitting these requires creating up to two IL stubs for each explicit tailcall in the function, and those stubs are not currently shared, so the rejit will always recreate them.
ghost
locked as resolved and limited conversation to collaborators
Currently we always promote methods with explicit tails to tier1 (and enable opts even in Debug?) so we never instrument them...
From my understanding, QJFL=1 (which is 0 by default) ideally implies a working OSR so we should not hit potential SO
/cc @AndyAyersMS @jakobbotsch