-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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: revise inlinee scale computations #51593
Conversation
Rework the inlinee profile scale computations so that all scaling happens during the profile incorporation phase, rather than sometimes deferring the scaling until inlining. Because of this we no longer need to record the scale on the inline info. Toss out profile data if all counts are zero. Update the edge profile solver to handle a special case where no return block was executed, but edges within the method had counts. In such cases the entry block count can end up zero and blocking proper scaling computations. For this case, try and deduce a plausible count in this case from nearby blocks and edges. Fix the edge weight computations to tolerate inconsistent data rather than to assert.
cc @dotnet/jit-contrib Before this change many inlinee internal blocks had disproportionally large of weights. For example:
Summary of SPMI diffs below. There is a large set of diffs in crossgen from the classic IBC data that exists there. Looked at a few of the larger regressions and they're from CSEs we no longer think are profitable. asm.aspnet.run.windows.x64.checked
Detail diffs
asm.benchmarks.run.windows.x64.checked
Detail diffs
asm.libraries.crossgen.windows.x64.checked
Detail diffs
asm.libraries.crossgen2.windows.x64.checked
Detail diffs
asm.libraries.pmi.windows.x64.checked
Detail diffs
asm.tests.pmi.windows.x64.checked
Detail diffs
|
Failures are known (#51607). |
Rework the inlinee profile scale computations so that all scaling happens
during the profile incorporation phase, rather than sometimes deferring
the scaling until inlining. Because of this we no longer need to record
the scale on the inline info.
Toss out profile data if all counts are zero.
Update the edge profile solver to handle a special case where no return block
was executed, but edges within the method had counts. In such cases the entry
block count can end up zero and blocking proper scaling computations. For this
case, try and deduce a plausible count in this case from nearby blocks and edges.
Fix the edge weight computations to tolerate inconsistent data rather than
to assert.