JIT: Remove bbFallsThrough restriction in fgOptimizeEmptyBlock

[amanasifkhalid]

Now that the JIT's implicit fallthrough assumption for certain block kinds is gone, we should start stripping out any logic dependent on bbFallsThrough. Note that fgReorderBlocks makes several decisions using bbFallsThrough -- I hope we can get rid of all of that in one go when we try a new block layout algorithm.

As for this change to fgOptimizeEmptyBlock, the pattern of always placing a BBJ_ALWAYS after a BBJ_COND to maintain implicit fallthrough is gone, so if we have a BBJ_COND block that "falls through" to an empty BBJ_ALWAYS that jumps somewhere else, this is logically equivalent to the BBJ_COND's false successor simply being the target of the BBJ_ALWAYS block, so we should have no problem removing the latter block. However, this creates churn during later optimization phases...

[dotnet-policy-service]

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

[AndyAyersMS]

However, this creates churn during later optimization phases...

Not sure I understand. Are you saying you're not going as far as you wanted to with this change?

[amanasifkhalid]

Not sure I understand. Are you saying you're not going as far as you wanted to with this change?

Sorry for the confusion, I didn't mean to imply I was holding back. With this change, we will now remove empty BBJ_ALWAYS blocks that succeed BBJ_COND blocks in the blocklist, as we no longer require implicit fallthrough between them. This change to the flowgraph isn't semantically significant, as bbFalseEdge models the new target the same way we previously modelled false jumps with fallthrough into a BBJ_ALWAYS. But like previous fallthrough removal changes, this change exposes fgReorderBlocks's sensitivity to these flowgraph modifications, as shown by the diffs.

[AndyAyersMS]

At least superficially the diffs look great, including some nice TP wins.