Skip to content
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

Closed
Tracked by #74873
AndyAyersMS opened this issue Jan 12, 2021 · 3 comments
Closed
Tracked by #74873

JIT: refactor edge weight representation #46885

AndyAyersMS opened this issue Jan 12, 2021 · 3 comments
Assignees
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone

Comments

@AndyAyersMS
Copy link
Member

AndyAyersMS commented Jan 12, 2021

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

@dotnet-issue-labeler 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 AndyAyersMS added this to the 6.0.0 milestone Jan 12, 2021
@AndyAyersMS AndyAyersMS removed the untriaged New issue has not been triaged by the area owner label Jan 12, 2021
@AndyAyersMS AndyAyersMS mentioned this issue Jan 12, 2021
54 tasks
@AndyAyersMS
Copy link
Member Author

See master...AndyAyersMS:EdgeWeights for a preliminary attempt.

@JulieLeeMSFT JulieLeeMSFT added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Mar 23, 2021
@AndyAyersMS
Copy link
Member Author

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 AndyAyersMS removed the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Mar 30, 2021
@AndyAyersMS AndyAyersMS modified the milestones: 6.0.0, Future Mar 30, 2021
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.
@AndyAyersMS
Copy link
Member Author

This is now done... #99736

@github-project-automation github-project-automation bot moved this from PGO to Done in .NET Core CodeGen Sep 3, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Oct 4, 2024
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
Projects
Status: Done
Development

No branches or pull requests

2 participants