Block inlining of IntroSort #89310
Block inlining of IntroSort #89310
Conversation
With PGO and (via dotnet#88749) one level of recursive inlining enabled, the jit sees the recursive call made by `IntroSort` as an attractive inline candidate, but it isn't. Fixes dotnet#89106.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@EgorBo @stephentoub PTAL Benchmark is pretty noisy but this should resolve the regressions we've seen.
|
teo-tsirpanis
added
area-System.Runtime
and removed
area-CodeGen-coreclr
|
Tagging subscribers to this area: @dotnet/area-system-runtime |
| @@ -2207,6 +2207,7 @@ private void IntrospectiveSort(int left, int length) | |||
| } | |||
| } | |||
|
|
|||
| [MethodImpl(MethodImplOptions.NoInlining)] | |||
There was a problem hiding this comment.
Can we include a comment as to why this is here? I imagine the calculus around whether this is valuable could change in the future.
There was a problem hiding this comment.
Added.
Note IntroSort is nominally doubly recursive but has already had the tail recursive call transformed into a loop manually. If we were ever tempted to undo that and rely on the JIT to do something similar, we might find the NoInline annotation would inhibit that transformation too.
@EgorBo we might consider special heuristics for recursion, generally if the method is large and doesn't have a frequent fast path that avoids recursion, then there's not much to be gained.
|
Perf has returned to "normal" Note there is a longer-term regression here from PGO, see #87194. |
ghost
locked as resolved and limited conversation to collaborators
With PGO and (via #88749) one level of recursive inlining enabled, the jit sees the recursive call made by
IntroSortas an attractive inline candidate, but it isn't.Fixes #89106.