================
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/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
