[llvm] [WebAssembly] Reapply "[WebAssembly] Incorporate SCCs into WebAssemblyFixIrreducibleControlFlow" (#181755) (PR #184441)

[Demetrius Kanios via llvm-commits]

================

----------------
QuantumSegfault wrote:

Yes, this is a VERY specific edge case where the translation from IR to DAG (or gMIR) orphans a block. It detects that the default branch target is just a dead-end `unreachable` IR _instruction_ and optimizes the target out during the translation step. But since it happens during translation, rather than earlier in a IR level optimization pass that would occur at `O2` (and likely `O1`; so we only run into this at `O0`), the target block is never cleaned up by DCE. It floats around orphaned, even though it can't be accessed anymore. It can't have any successors, as it must end in `unreachable`, so two chained BBs is not a concern here.

I don't know of any other case where we'd orphan a whole MBB chain without cleaning it up (though that's not saying much...).

But really, if there's any other significant cases of unreachable MBB, we should probably incorporate a full unreachable (machine ) basic block eliminator into the pipeline sometime before (or even during) this pass, even at O0. No sense in fixing, reordering, structuring, and emitting dead branches of the CFG.

---------

The previous code did things in such a way that even blocks not accessible from the Entry of a region (which is only ever possible for the initial call to processRegion spanning the whole function) would still map out the full network of for EACH block included in the "region", which other blocks could be transiently reached. Even isolated bubbles would be checked correctly, albeit inefficiently. The assumption made by our use of SCCs is that every relevant block is accessible from the entry of the region (otherwise, why is it even in the region???). I included an assertion to verify my assumption, which got tripped here.

https://github.com/llvm/llvm-project/pull/184441