Handle irreducible control flow in branch simplification

[fitzgen]

We previously removed a block from the CFG if it was not marked as reachable by the time the egraph pass visited it. The pass's traversal is both (1) a depth-first pre-order dominator traversal, and (2) a reverse post-order CFG traversal. This traversal visits all of a block's non-back edge predecessors before visiting the block itself. For reducible control flow, this is all that is necessary because we've already visited every back edge's target block already.

However, for irreducible control flow, blocks can be reachable only through back edges, and so the traversal's property alone was not sufficient. (The EgraphBlockIter's proof is still correct, at least to the best of my knowledge since we haven't mechanically proven it, but the implicit assumption that its proven property is sufficient for our reachability-based block removal is incorrect in the face of irreducible control flow.)

This commit's fix is to stop removing newly-unreachable blocks in the middle of the egraphs pass, and instead simply call eliminate_unreachable_code after the egraph pass completes to remove any code that became unreachable after branch simplification.

Fixes #13365

[cfallin]

Thanks. I think we'll need to change the design here: this is making elaboration more complex (to be tolerant of unreachable code) and then doing DCE; I would have expected us not to elaborate unreachable blocks, instead.

[fitzgen]

@cfallin I updated the PR to call eliminate_unreachable_code in the middle of the egraph pass, after optimizing and removing instructions, but before elaboration. Probably easiest to look at the complete diff, rather than per-commit.

[cfallin]

LGTM, thanks!