Don't run optJumpThreading when fgCurBBEpochSize != (fgBBNumMax + 1)

[EgorBo]

Fixes #71599

[ghost]

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

Issue Details

---

Fixes #71599

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

[EgorBo]

So the problem that optLoopHoist phase creates a new block here, it invalidates the assumption that fgCurBBEpochSize == (fgBBNumMax + 1)

optJumpThreading seems to not like it when it does BlockSetOps::AddElemD under the hood.

It seems to me that we can't just re-calculate doms and renumber blocks in-between loopHoist and optRedundantBranch phases (due to SSA state?)

so this fix works but it has some diffs. What do you think @AndyAyersMS @BruceForstall

runtime/src/coreclr/jit/compiler.cpp

Lines 4948 to 4965 in 215d7e4

	if (doLoopHoisting)
	{
	// Hoist invariant code out of loops
	//
	DoPhase(this, PHASE_HOIST_LOOP_CODE, &Compiler::optHoistLoopCode);
	}
	if (doCopyProp)
	{
	// Perform VN based copy propagation
	//
	DoPhase(this, PHASE_VN_COPY_PROP, &Compiler::optVnCopyProp);
	}
	if (doBranchOpt)
	{
	DoPhase(this, PHASE_OPTIMIZE_BRANCHES, &Compiler::optRedundantBranches);
	}

[AndyAyersMS]

Seems like an appropriate fix for now.

We really need to start eagerly creating preheaders, so hoisting can stop modifying the flow graph.

[AndyAyersMS]

I would put this check down at the start of optJumpThread.

[AndyAyersMS]

optJumpThread doesn't really depend on the epoch, it depends onBlockSet which depends on the epoch.

Down the road we should consider giving optJumpThread alternative ways of keeping track of the different sets of preds, I only used BlockSet here because it seemed convenient. The pred sets are likely going to be pretty small (most blocks don't have many preds) so something simpler might actually both remove this dependency and be more efficient overall.

I'll add a note to #48115.

[EgorBo]

Failure is #72429