-
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: refactor edge weight representation #46885
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone
Comments
dotnet-issue-labeler
bot
added
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
untriaged
New issue has not been triaged by the area owner
labels
Jan 12, 2021
AndyAyersMS
removed
the
untriaged
New issue has not been triaged by the area owner
label
Jan 12, 2021
See master...AndyAyersMS:EdgeWeights for a preliminary attempt. |
JulieLeeMSFT
added
the
needs-further-triage
Issue has been initially triaged, but needs deeper consideration or reconsideration
label
Mar 23, 2021
Would like to find room for this in 6.0 but it may be too disruptive and the gains (aside from much cleaner code in the jit proper are unknown). So moving to future. |
AndyAyersMS
removed
the
needs-further-triage
Issue has been initially triaged, but needs deeper consideration or reconsideration
label
Mar 30, 2021
10 tasks
AndyAyersMS
added a commit
to AndyAyersMS/runtime
that referenced
this issue
Feb 10, 2023
Dump flow graph before running post-phase checks so the flow graph visualization can be used in conjunction with the profile checker output to spot profile problems. Various provisional fixes to try and shore up the inevitably inconsistent OSR profile. Add a compensating pseudo-edges to the OSR entry to help explain where the missing flow counts have gone. Relax checking for the OSR entry. Add likelhood when we redirect flow to the OSR entry. Locate the OSR entry and original method entry early so we can special-case them in diagnostics. Defer marking interesting blocks (say for switch peeling) until we've set edge likelihoods, since (someday) those decisions should use edge likelihoods. Disable profile checking after profile incorporation. The plan is to walk this disable back incrementally and fix issues in each succesive phase, ultimately checking them all. But currently we still have a lot of check failures right after this first phase. Contributes to dotnet#46885.
AndyAyersMS
added a commit
that referenced
this issue
Feb 13, 2023
Dump flow graph before running post-phase checks so the flow graph visualization can be used in conjunction with the profile checker output to spot profile problems. Various provisional fixes to try and shore up the inevitably inconsistent OSR profile. Add a compensating pseudo-edges to the OSR entry to help explain where the missing flow counts have gone. Relax checking for the OSR entry. Add likelhood when we redirect flow to the OSR entry. Locate the OSR entry and original method entry early so we can special-case them in diagnostics. Defer marking interesting blocks (say for switch peeling) until we've set edge likelihoods, since (someday) those decisions should use edge likelihoods. Disable profile checking after profile incorporation. The plan is to walk this disable back incrementally and fix issues in each succesive phase, ultimately checking them all. But currently we still have a lot of check failures right after this first phase. Contributes to #46885.
This is now done... #99736 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Modify how we represent edge weights in the jit; instead of being discrete weight values they should be computed as the product of the source block's weight times its successor likelihood. Also, we should just have one weight value instead of the current min/max weights.
The goal here is to change the maintenance burden from updating weights to updating likelihoods, so profile maintenance is more block centric.
Edge weights are currently only used / computed during PGO. If we adopt an edge-based profiling scheme (as proposed in #46882) then edge weights will initially be the primary source of data.
This also lays the groundwork for profile synthesis.
First bit of this has landed: #81738
category:cq
theme:profile-feedback
skill-level:expert
cost:large
The text was updated successfully, but these errors were encountered: