JIT: Remove some fgRenumberBlocks calls
#110026
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
src/coreclr/jit/compiler.cpp
Outdated
| // Ensure the BB epoch is up to date before running loop hoisting to avoid false positives. | ||
| // TODO-bbNum: Either replace this check with a breadcrumb like 'fgModified', | ||
| // or relax jump threading's prerequisites. | ||
| EnsureBasicBlockEpoch(); |
There was a problem hiding this comment.
On second thought, we should be able to get rid of RBO's dependency on block epoch altogether. Let me do that first.
Part of #107749. Prerequisite for #110026. Use postorder number-based BitVecs in RBO and block layout. Use bbID-based BitVecs in fgIncorporateProfileData. This runs early enough in the JIT frontend such that I would expect bbIDs and bbNums to be 1:1, so I don't expect any TP impact from this change. Switch descriptor creation still uses bbNums as a key into a BitVec as a workaround for BB epoch invariants -- I'll try switching this over to bbID in a follow-up to evaluate the TP cost of a sparser bitset.
|
cc @dotnet/jit-contrib, @jakobbotsch PTAL. Small diffs. The Instrumented Tier0 diffs stem from the fact that bbNums are used in key computations by |
We can change this to use |
Do we have anything to gain from switching this over to |
|
Follow-up to #110026. This required a small refactor of FlowGraphNaturalLoop::VisitLoopBlocksLexical to remove its bbNum checks.
…0034) Part of dotnet#107749. Prerequisite for dotnet#110026. Use postorder number-based BitVecs in RBO and block layout. Use bbID-based BitVecs in fgIncorporateProfileData. This runs early enough in the JIT frontend such that I would expect bbIDs and bbNums to be 1:1, so I don't expect any TP impact from this change. Switch descriptor creation still uses bbNums as a key into a BitVec as a workaround for BB epoch invariants -- I'll try switching this over to bbID in a follow-up to evaluate the TP cost of a sparser bitset.
Follow-up to dotnet#110026. This required a small refactor of FlowGraphNaturalLoop::VisitLoopBlocksLexical to remove its bbNum checks.
Part of #107749. While we cannot get rid of
fgRenumberBlocksaltogether yet, this gets us close. The JIT still as a few hard dependencies on bbNums reflecting relative lexical order:optSetBlockWeightswill use bbNums for naive loop backedge detection.fgRenumberBlockscalls in loop cloning/unrolling in-place for now.There's also a soft dependency on bbNum ordering in
fgUpdateFlowGraphthat can trigger diffs. These diffs were quite small locally, so I think we can tolerate them for now.