JIT: allow inliner to use up more of the lva "budget" #118515
Conversation
We currently stop inlining once we hit a fixed limit of 512 local vars (specified via `MAX_LV_NUM_COUNT_FOR_INLINING`). We hit this limit now more often because of increased inliner aggressiveness, and at any rate it should be some fraction of `JitMaxLocalsToTrack` instead of a fixed value. When the inliner hits this limit it often leaves quite valuable inlines on the table. Revise this so the inliner is allowed to consume 90% of the max locals during inlining (50% would be a no-diff change). This fixes some regressions reported in dotnet#114996 which were then made worse by dotnet#116054.
github-actions
bot
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
This PR changes how the JIT inliner determines when to stop inlining due to local variable limits. Instead of using a hard-coded limit of 512 locals, it now uses 90% of the dynamically configured maximum locals to track (JitMaxLocalsToTrack).
- Replaces fixed
MAX_LV_NUM_COUNT_FOR_INLININGconstant with a percentage-based check - Allows the inliner to use up to 90% of the available local variable budget
- Aims to address performance regressions by enabling more valuable inlining opportunities
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@dotnet/jit-contrib FYI I think we should seriously consider taking this for .NET 10, we can always tune it back later if we don't like the results. No way to get a clear read short of running in the perf lab. |
tannergooding
left a comment
tannergooding
left a comment
There was a problem hiding this comment.
Seems like a positive change all around
|
Do you know what the spmi diff failures are from? It looks like a few threw exceptions but it isn’t clear from the log what actually marked it as “failed”. Seems like a potential infra issue (non blocking) we might want to track getting resolved |
It looks like JIT is segfaulting. I see it on other runs of superpmi-diffs too. I opened #118522 for it. |
|
@EgorBot --intel --arm --filter |
4 participants
We currently stop inlining once we hit a fixed limit of 512 local vars (specified via
MAX_LV_NUM_COUNT_FOR_INLINING). We hit this limit now more often because of increased inliner aggressiveness, and at any rate it should be some fraction ofJitMaxLocalsToTrackinstead of a fixed value.When the inliner hits this limit it often leaves quite valuable inlines on the table.
Revise this so the inliner is allowed to consume 90% of the max locals during inlining (50% would be a no-diff change).
This fixes some regressions reported in #114996 which were then made worse by #116054.