[PATCH] D15325: [WinEH] Update CoreCLR EH state numbering

[Andy Kaylor via llvm-commits]

andrew.w.kaylor added inline comments.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:452
@@ +451,3 @@
+    if (auto *CPI = dyn_cast<CleanupPadInst>(FirstNonPHI)) {
+      if (CPI->getCleanupRetUnwindDest())
+        // This will be visited from its unwind dest
----------------
I have to admit that I'm not familiar enough with Core CLR to know what's possible and what isn't, so maybe this isn't an issue, but it strikes me here that a nested cleanup pad that never returns will be treated like a top level cleanup pad.  I'm thinking of something like this:
```
try {
  try {
    f()
  } catch (...) {
    try {
      g()
    } finally {
      throw() // noreturn
    }
  }
} catch (...) {
}
```
The throw call here would unwind to the outer catch handler, but I think CPI->getCleanupRetUnwindDest() would return null.

================
Comment at: lib/CodeGen/WinEHPrepare.cpp:456
@@ +455,3 @@
+    } else if (auto *CSI = dyn_cast<CatchSwitchInst>(FirstNonPHI)) {
+      if (CSI->getUnwindDest())
+        // This will be visited from its unwind dest
----------------
I'm probably not understanding this correctly.  Can you talk me through how a case like the following would be handled?
```
try {
  try {
  } catch { // inner catch
  }
} catch { // outer catch
  try {
  } catch { // catch catch
  }
}
```
If I have everything straight, both "outer catch" and "catch catch" will have null unwind destinations.  So that would make the parent state of "catch catch" -1, I think.  Is that what you want?



http://reviews.llvm.org/D15325