[PATCH] D15139: [IR] Reformulate LLVM's EH funclet IR

Reid Kleckner via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 11 09:39:10 PST 2015


rnk added inline comments.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:223-231
@@ -250,11 +222,11 @@
 
-static void calculateExplicitCXXStateNumbers(WinEHFuncInfo &FuncInfo,
-                                             const BasicBlock &BB,
-                                             int ParentState) {
-  assert(BB.isEHPad());
-  const Instruction *FirstNonPHI = BB.getFirstNonPHI();
-  // All catchpad instructions will be handled when we process their
-  // respective catchendpad instruction.
-  if (isa<CatchPadInst>(FirstNonPHI))
-    return;
+static void calculateCXXStateNumbers(WinEHFuncInfo &FuncInfo,
+                                     const Instruction *FirstNonPHI,
+                                     int ParentState) {
+  const BasicBlock *BB = FirstNonPHI->getParent();
+  assert(BB->isEHPad() && "not a funclet!");
+
+  if (auto *CatchSwitch = dyn_cast<CatchSwitchInst>(FirstNonPHI)) {
+    assert(FuncInfo.EHPadStateMap.count(CatchSwitch) == 0 &&
+           "shouldn't revist catch funclets!");
 
----------------
It really could. Comments fell by the wayside because we were impatiently trying to pair program something that would work.

I'm probably the person who should write them, though, so I'd rather commit this and then try to clean up the algorithm in tree.

There's other stuff to do as well. It would be good to share the EH traversal between the CLR, C++, and SEH, so this is probably going to get rewritten.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:250
@@ +249,3 @@
+    for (const auto *CatchPad : Handlers) {
+      FuncInfo.FuncletBaseStateMap[CatchPad] = CatchLow;
+      for (const User *U : CatchPad->users()) {
----------------
> This assigns the same base state to all catchpads within a catchswitch. That seems sketchy to me.

That's not actually different from how things work with catchendpad today, and I think it's consistent with what MSVC does. Here's how I read the states produced by MSVC on your example:
  void f(int);
  void foo() {
    try {
      f(1); // state 0
    } catch (int) {
      f(2); // state 1
      try {
        f(3); // state 2
      } catch (...) {
        // state 3
      }
    } catch (...) {
      f(4); // state 1
      try {
        f(5); // state 4
      } catch (...) {
        // state 5
      }
    }
  }
  // unwind map
  // 0 -> -1
  // 1 -> -1
  // 2 -> 1
  // 3 -> 1
  // 4 -> 1
  // 5 -> 1

Clang today computes the same table as MSVC on this example, and I'm pretty sure this patch will keep our behavior here the same.


http://reviews.llvm.org/D15139





More information about the llvm-commits mailing list