[PATCH] D154294: [Windows SEH]: Do not fold branches for MSVC TableSEH function

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

I wanted to follow up on this, it was hiding at the bottom of my inbox.

To recap the issue, what's going on is that with asynch EH enabled, it is now possible for machine CFG cleanups in branch folding to delete basic blocks and make some funclets unreachable. This causes problems because we store references to funclet entry MBBs in WinEHFuncInfo. The ability to do this relies on the assumption that Machine passes are just not powerful enough to delete branches to funclets, usually because they are reachable from an invoke, and that's not something a machine pass can normally delete.

However, with asynch EH, we have these no-op @llvm.seh.try.begin/end intrinsics. They don't become real call instructions, so they don't create the same kind of optimization barrier that synchronous EH would have. If you look at the machine CFG posted earlier, you see a sequence of MBBs containing nothing but JMPs, and BranchFolding::OptimizeBranches is trying to clean that up into a straightline fallthrough and delete the intermediate basic blocks. Doing that deletes the successor edges to the catch and cleanup funclets, and then the blocks themselves once they become unreachable.

This raises the question of if we should try to make WinEHFuncInfo resilient to these kinds of CFG changes, and I think the answer is "definitely not", because we calculate the state numbers on the LLLVM IR much earlier during WinEHPrepare.

I think the next step is to dig into OptimizeBlock and teach it not to remove blocks for which hasEHPadSuccessor is true.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154294/new/

https://reviews.llvm.org/D154294