-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: fix recursive inline check #88749
Conversation
The existing check was too conservative, and blocked inlines of one instantation of a generic method into a different instantiation of the same method, or of two different methods that share the exact same IL stream. Generalize the check to also compare the method handle and runtime context. Fixes dotnet#88667 Fixes dotnet#58824
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThe existing check was too conservative, and blocked inlines of one instantation of a generic method into a different instantiation of the same method, or of two different methods that share the exact same IL stream. Generalize the check to also compare the method handle and runtime context.
|
@EgorBo PTAL Per jit-diff, fairly minimal diffs overall. The WebCIL diffs are cases like we see in #88667.
Per BenchmarkDotNet, this fixes the perf regressions from #88667.
|
Suspect is is fallout from #88692 |
Opened issues for the failures, not sure if/when build analysis will update to show this. |
Errors are known. |
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.
…ecursive methods The inliner heuristics do not take into account that inlining methods causes type/method loading of the generic context. After dotnet#88749 this can quickly cause significant resources to be consumed as part of inlining when polymorphic recursion is involved (the blow-up can be exponential, as we see in the failing test under jitstress). This PR adds another safe-guard to the recursive inlining check in terms of a complexity limit on the generic context of the inline candidate. Fix dotnet#90144
…ecursive methods (#90306) The inliner heuristics do not take into account that inlining methods causes type/method loading of the generic context. After #88749 this can quickly cause significant resources to be consumed as part of inlining when polymorphic recursion is involved (the blow-up can be exponential, as we see in the failing test under jitstress). This PR adds another safe-guard to the recursive inlining check in terms of a complexity limit on the generic context of the inline candidate. Fix #90144
The existing check was too conservative, and blocked inlines of one instantation of a generic method into a different instantiation of the same method, or of two different methods that share the exact same IL stream.
Generalize the check to also compare the method handle and runtime context.
Fixes #88667
Fixes #58824