JIT: Flowgraph Modernization and Improved Block Layout in .NET 10 #107749
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
User Story
A single user-facing feature. Can be grouped under an epic.
Milestone
Continuation of #93020. During the .NET 9 development cycle, we removed much of the JIT flowgraph implementation's implicit fall-through invariants, and introduced a new block layout strategy based on a reverse post-order traversal of the graph. For .NET 10, we'd like to push this work further in both directions, with the ultimate goals of zero dependence on lexical block ordering in the JIT's frontend, and a global cost-optimizing layout algorithm in the JIT's backend. Below is an early estimate of what each item entails:
Flowgraph Modernization
fgUpdateFlowGraph
that we usually run in conjunction with layout aren't designed to run after lowering, so we will likely need to decouple flow opts from layout to make this work.fgNewBBinRegion
may search the block list for insertion points that won't break up existing fall-through. In the JIT frontend, it should make no difference to optimization potential if we just insert new blocks at the end of the list, or at the end of an EH region. Doing this work early should help expose frontend phases that are still sensitive to lexical block ordering (see next task).Compiler::fgSplitEdge
#107419optSetBlockWeights
(see Profile Data section)BBJ_NONE
block type left behind breadcrumbs in various phases that we ought to clean up, now that we can model flow explicitly.fgUpdateFlowGraph
.Block layout
Ideally, the below items get us to a state where block layout produces the "best" ordering it can, given the profile data it has on-hand. If the layout is subpar due to missing/inconsistent profile data, we can at least eliminate the layout strategy as the culprit.
Profile Maintenance
optSetBlockWeights
with the new profile synthesis implementation. The former frequently produces nonsensical weights for loops, as it relies on a lexical traversal of the block list to identify loops. Fixing this may improveJitOptRepeat
performance.BBJ_THROW
block is hot, then order it as such (this particular example is not as perf-sensitive, though).cc @dotnet/jit-contrib, @AndyAyersMS
The text was updated successfully, but these errors were encountered: