JIT: Reuse (new) loop-finding DFS tree in SSA

[jakobbotsch]

• Add a new phase to canonicalize the entry BB, way back before we compute reachability
• Switch SSA to reuse the DFS tree computed for (new) loop finding
• Switch SSA to use post-order traits instead of bbNum-based traits
• Quirk old loop finding to avoid finding new loops now

Some improvements are expected from RBO no longer getting caught up in this early-out:

runtime/src/coreclr/jit/redundantbranchopts.cpp

Lines 766 to 770 in 9080024

	if (fgCurBBEpochSize != (fgBBNumMax + 1))
	{
	JITDUMP("Looks like we've added a new block (e.g. during optLoopHoist) since last renumber, so no threading\n");
	return false;
	}

[ghost]

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

Issue Details

---

• Add a new phase to canonicalize the entry BB, way back before we compute reachability
• Switch SSA to reuse the DFS computed for (new) loop finding
• Switch SSA to use post-order traits instead of bbNum-based traits

Author:	jakobbotsch
Assignees:	jakobbotsch
Labels:	area-CodeGen-coreclr
Milestone:	-

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @AndyAyersMS @BruceForstall

Diffs. ASM diffs from the RBO case mentioned above. TP improvements from doing one less DFS.

[BruceForstall]

LGTM.

I wonder if we could simplify things by just always creating a "scratch" first BB when the flow graph is created, and then teaching flow opts (e.g., block compaction) to not remove it even if empty. Then we could get rid of fgEnsureFirstBBisScratch and this new phase. Codegen wouldn't generate any code if the block ends up empty.

[jakobbotsch]

I wonder if we could simplify things by just always creating a "scratch" first BB when the flow graph is created, and then teaching flow opts (e.g., block compaction) to not remove it even if empty. Then we could get rid of fgEnsureFirstBBisScratch and this new phase. Codegen wouldn't generate any code if the block ends up empty.

Yeah, I think that kind of canonicalization would be good. It would also benefit us earlier by allowing us to use the DFS I added in #95726 in e.g. physical promotion. Currently physical promotion may need to create a scratch BB and would thus invalidate the DFS tree.