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

Wed Aug 30 18:52:55 PDT 2023

pengfei added a comment.

Thanks @rnk and @efriedma for the follow up. FYI, I have disabled BranchFolding and MachineBlockPlacement for asynch EH internally to workaround this problems. We can improve them, but it's not my top priority at the present.

> 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.

I was trying to define pseudo opcodes for these intrinsics, but it cannot solve MachineBlockPlacement issue because it's behind the pseudo expansion pass.

> 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.

> We can continue with a fictional, imperfect Machine CFG, and attempt to retain the seh.try.end intrinsics by adding a fictional edge from begin to end, so unreachable won't destroy the try scope information

The design doc <https://reviews.llvm.org/D80344> says "If some exits flow to unreachable, propagation on those paths terminate, not affecting remaining blocks.". I think there might be some performance affects if we intended to retain these BBs. If we can accept some performance lose, I think disbling the pass is a better choice.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154294