[PATCH] Initial SEH IR generation implementation

[John McCall]

I think the best solution here is definitely to let the backend handle outlining handler functions: to get reasonable code, the outlining has to be done by something that understands the layout of the outer function's frame, and only the backend can do that.  No high-level intrinsic can capture the relationship between the functions in any sort of reliable way without completely disabling inlining of the outer function.  And we really want to still be able to do data-flow optimizations in the outer function; we just have to ensure that any live-in values have been spilled to the stack at the call site.

Unfortunately, I think the same principle is going to end up applying to filter functions.  If they don't use values from the enclosing frame, then fine, you can outline them in the frontend; but if they do there's just no way that a frontend solution is ever going to work.  This might mean that we need to change the invoke IR pattern again so that the filter functions are just basic blocks within the function (which end in some special intrinsic/instruction that guides outlining).

I think you need to have that conversation on the LLVM side before you can make any useful progress on the Clang side.  Please CC me on that conversation when you start it.

================
Comment at: lib/CodeGen/CGException.cpp:113
@@ +112,3 @@
+      CGM.getTarget().getCXXABI().isItaniumFamily()) {
+    name = "_ZSt9terminatev";
+  } else if (CGM.getLangOpts().ObjC1 &&
----------------
Seems like a reasonable thing for the CXXABI to return.

================
Comment at: lib/CodeGen/CGException.cpp:437
@@ +436,3 @@
+  const EHPersonality &P = EHPersonality::get(CGM);
+  return StringRef("__C_specific_handler") == P.PersonalityFn;
+}
----------------
Don't do this.  Make a flag somehow.

http://reviews.llvm.org/D5607