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: Remove some early fgReorderBlocks calls #97012

Merged
merged 1 commit into from
Jan 16, 2024

Conversation

amanasifkhalid
Copy link
Member

Before finalizing the block layout with optOptimizeLayout, we call fgReorderBlocks in a few optimization passes that modify the flowgraph (though without the intent to actually reorder any blocks, by passing useProfile=false). Removing all of these early calls -- except for the one in optOptimizeFlow, which can probably be replaced by moving fgReorderBlocks's branch optimization logic to fgUpdateFlowGraph -- incurs relatively few diffs, and gets us closer to #93020's goal of deferring block reordering until late in the JIT's optimization phases.

@ghost ghost assigned amanasifkhalid Jan 16, 2024
@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jan 16, 2024
@ghost
Copy link

ghost commented Jan 16, 2024

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

Before finalizing the block layout with optOptimizeLayout, we call fgReorderBlocks in a few optimization passes that modify the flowgraph (though without the intent to actually reorder any blocks, by passing useProfile=false). Removing all of these early calls -- except for the one in optOptimizeFlow, which can probably be replaced by moving fgReorderBlocks's branch optimization logic to fgUpdateFlowGraph -- incurs relatively few diffs, and gets us closer to #93020's goal of deferring block reordering until late in the JIT's optimization phases.

Author: amanasifkhalid
Assignees: amanasifkhalid
Labels:

area-CodeGen-coreclr

Milestone: -

@amanasifkhalid
Copy link
Member Author

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs are pretty small; would you prefer removing these fgReorderCalls altogether and doing the fgOptimizeBranch pass later (maybe after block layout is finalized)? Or should we replace these calls with a pass over the block list that makes the calls to fgOptimizeBranch more explicit?

@EgorBo
Copy link
Member

EgorBo commented Jan 16, 2024

Diffs are pretty small;

Presumably because "Insert GC polls" is a rare thing, it only kicks in for methods containing pinvokes + [SuppressGCTransition]

Copy link
Member

@EgorBo EgorBo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AndyAyersMS
Copy link
Member

cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs are pretty small; would you prefer removing these fgReorderCalls altogether and doing the fgOptimizeBranch pass later (maybe after block layout is finalized)? Or should we replace these calls with a pass over the block list that makes the calls to fgOptimizeBranch more explicit?

Let's remove them like you are doing here. Ultimately most phases should not care about ordering and we will have some sort of flow graph simplification that we will call from time to time (perhaps after every phase that changes flow, if it's cheap enough, since the changes should hopefully be fairly straightforward).

As for "final" cleanup I think we will do it just before (or as a first step) in final layout.

@amanasifkhalid amanasifkhalid merged commit aa974c7 into dotnet:main Jan 16, 2024
126 of 129 checks passed
@amanasifkhalid amanasifkhalid deleted the reduce-reordering branch January 16, 2024 21:11
tmds pushed a commit to tmds/runtime that referenced this pull request Jan 23, 2024
Before finalizing the block layout with optOptimizeLayout, we call fgReorderBlocks in a few optimization passes that modify the flowgraph (though without the intent to actually reorder any blocks, by passing useProfile=false). Removing all of these early calls -- except for the one in optOptimizeFlow, which can probably be replaced by moving fgReorderBlocks's branch optimization logic to fgUpdateFlowGraph -- incurs relatively few diffs, and gets us closer to dotnet#93020's goal of deferring block reordering until late in the JIT's optimization phases.
@github-actions github-actions bot locked and limited conversation to collaborators Feb 16, 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
None yet
Development

Successfully merging this pull request may close these issues.

3 participants