[PATCH] Initial SEH IR generation implementation

[Reid Kleckner]

================
Comment at: lib/CodeGen/CGException.cpp:1821
@@ +1820,3 @@
+    }
+    Builder.CreateCall(FilterIntrin, R);
+
----------------
rjmccall wrote:
> rnk wrote:
> > rjmccall wrote:
> > > Shouldn't you be branching on the filter result or something?  It feels wrong for the control flow here to be implicit.
> > The idea in this patch is that we enter the landing pad, and we sort of non-determinstically already know what the selector is. The `@llvm.eh.seh.filter` call acts as a barrier against code motion of side effects. It's kind of like a suspend / resume point in a coroutine. What happens in practice is that the code between the typeid check and the `@llvm.eh.seh.filter` call gets outlined.
> > 
> > Now that I'm thinking about this harder, I'll admit this is kind of broken for nested cleanups, as the cleanups will run before the filter, which is not what actually happens in practice (filters run during phase 1). =/
> > 
> > What do you think about going back to outlining filters in the frontend? I've had many weeks of coffee and whiteboard discussions trying to figure out the least disruptive way to fit filter functions into LLVM's EH scheme, and we haven't come up with anything good. We can still do backend outlining for cleanups and C++ EH. LLVM's EH model just doesn't have a place for code that gets executed during phase 1 EH unwinding.
> I think outlining filters is an acceptable implementation model given the oddity of the control flow.  Can we get away with just disallowing references to local variables in them for now, or is that an important use case?
We can definitely get away with rejecting local variable capture for now. I can't find any instances of it in the code I have available.

However, eventually we will need to support it, at which point I would want to use the `@llvm.frameallocate` `@llvm.framerecover` intrinsics. Those inhibit inlining, which I think is OK for this particular corner case. We already support similarly heinous extensions like labels as values that inhibit inlining. :)

================
Comment at: lib/Sema/SemaChecking.cpp:467
@@ +466,3 @@
+  case Builtin::BI_exception_code: {
+    Scope *S = getCurScope();
+    while (S && !S->isSEHExceptScope())
----------------
rjmccall wrote:
> rnk wrote:
> > rjmccall wrote:
> > > This checking can run in template instantiations, but getCurScope() isn't meaningful there.
> > Right. :( This is always a syntactic nesting property, though. Instantiation cannot change it. Should I just check it during the parse (if so, where?), or just suppress this Sema check during instantiation, since it will always give the same result?
> In theory, you can construct builtin calls in template instantiations with e.g. non-type template arguments.  It's probably safe to just not diagnose that well as long as you don't crash during IRGen if you miss a case.
> 
> You don't really have a choice about where you detect this; there *are* often separate Sema entrypoints for parsing vs. instantiation, but we don't want to burden every function call parse with an extra check just for this.  I think Sema tracks that's currently instantiating a function body, but I don't remember where.
OK. We'll produce undef for these during codegen if they sneak in some how.

http://reviews.llvm.org/D5607

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/