-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsBefore finalizing the block layout with
|
cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs are pretty small; would you prefer removing these |
Presumably because "Insert GC polls" is a rare thing, it only kicks in for methods containing pinvokes + [SuppressGCTransition] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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. |
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.
Before finalizing the block layout with
optOptimizeLayout
, we callfgReorderBlocks
in a few optimization passes that modify the flowgraph (though without the intent to actually reorder any blocks, by passinguseProfile=false
). Removing all of these early calls -- except for the one inoptOptimizeFlow
, which can probably be replaced by movingfgReorderBlocks
's branch optimization logic tofgUpdateFlowGraph
-- incurs relatively few diffs, and gets us closer to #93020's goal of deferring block reordering until late in the JIT's optimization phases.