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

[Phoebe Wang via Phabricator via llvm-commits]

pengfei added a comment.

In D154294#4630030 <https://reviews.llvm.org/D154294#4630030>, @efriedma wrote:

> In D154294#4629965 <https://reviews.llvm.org/D154294#4629965>, @pengfei wrote:
>
>>> We can continue with the existing IR by trying to identify try regions and adding extra unwind edges to MBBs in the try state
>>
>> In the previous analysis <https://reviews.llvm.org/D154294#4501026>, I thought the edges are preserved until we are merging them (e.g., bb.1 has two successors although it has absolute jump). And I thought the way to solve it is to inherit these successors when merging BBs. However, it may not solve all the problems, since BBs may have different EH states. The point is, I think such edges don't solve the problem here. Or we may have different understanding about adding edges.
>
> My understanding of "adding edges" is that in the example https://reviews.llvm.org/D154294#4501026, we would add an edge from 'bb.5.invoke.cont4' to the landing pad in the initial MIR CFG.  (Not adding the edge when we merge blocks in BranchFolding, but adding the edge when SelectionDAG constructs the MIR.)  The edge doesn't explicitly exist in the LLVM IR, but we can infer it from the preceding llvm.seh.try.begin() call.

`bb.5.invoke.cont4` to landing pad (I assume it's `bb.7.ehcleanup`) doesn't matter to me here. I analyzed the problem was the edge from `bb.3.invoke.cont2` to `bb.4.__except` was removed in BranchFolding. This is the direct problem I wanted to solve here. It seems we are talking about independent problems. I didn't research the other but I think it doesn't solve my problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154294