JIT: Set bbFalseTarget upon BBJ_COND initialization/modification

[amanasifkhalid]

Part of #93020. Previously, bbFalseTarget was hard-coded to match bbNext in BasicBlock::SetNext. We still require bbFalseTarget to point to the next block for BBJ_COND blocks, but I've removed the logic for updating bbFalseTarget from SetNext, and placed calls to SetFalseTarget wherever bbFalseTarget needs to be updated because the BBJ_COND block has been created or moved relative to its false successor. This helps set us up to start removing logic that enforces the block's false successor is the next block.

[ghost]

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

Issue Details

---

Part of #93020. Previously, bbFalseTarget was hard-coded to match bbNext in BasicBlock::SetNext. We still require bbFalseTarget to point to the next block for BBJ_COND blocks, but I've removed the logic for updating bbFalseTarget from SetNext, and placed calls to SetFalseTarget wherever bbFalseTarget needs to be updated because the BBJ_COND block has been created or moved relative to its false successor. This helps set us up to start removing logic that enforces the block's false successor is the next block.

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

[amanasifkhalid]

cc @dotnet/jit-contrib. No asmdiffs, and small TP diffs. SPMI failures are due to timeouts on win-x86.

I noticed that we only use Compiler::fgConnectFallThrough to connect BBJ_COND blocks to their fallthrough successors with a new BBJ_ALWAYS successor; this strategy doesn't work for connecting BBJ_CALLFINALLY blocks to their successors since Bruce introduced BBJ_CALLFINALLYRET. When inserting/moving blocks, we already avoid splitting up BBJ_CALLFINALLY/BBJ_CALLFINALLYRET pairs, and retless BBJ_CALLFINALLY blocks shouldn't fall through, so I don't think we'd expect to encounter a BBJ_CALLFINALLY block in Compiler::fgConnectFallThrough. Thus, I've cleaned this method up a bit.

[BruceForstall]

Should this function take a falseTarget parameter that is used to set bbFalseTarget? Then, callers would be required to set it. Maybe later on when we remove bbNext as fall through?

[amanasifkhalid]

That makes sense to me. I'll open a follow-up PR with that refactor; it might help others avoid hitting asserts around bbFalseTarget by forcing them to set it when initializing bbTrueTarget.

Thank you for the review!