[llvm-commits] [patch] Fix the inlining of invokes into invokes for libUnwind-like EH implementations

John McCall rjmccall at apple.com
Fri May 27 10:35:44 PDT 2011


On May 27, 2011, at 12:45 AM, Duncan Sands wrote:
>>> I think that the Ada front-end generates a call to _Unwind_Resume which takes more than one argument (and possibly a varargs).
>> 
>> I don't know how it would do that.
> 
> it doesn't with dragonegg:
>   declare void @_Unwind_Resume_or_Rethrow(i8*)
> 
> With llvm-gcc you get
>   declare void @_Unwind_Resume_or_Rethrow(i8*, ...)
> which is an accident of how it is generated and can be fixed.  I wouldn't
> worry about it.

Okay.  In an attempt to make this change more opt-in, I actually only do this forwarding for _Unwind_Resume, anyway.  _URR does not necessarily have the same semantics — in fact, that's why we've been using it instead — and I don't feel as comfortable applying the same forwarding trick to it.

Part of the point of this is actually to make it possible to use _Unwind_Resume again.

>> My understanding is that no component of a filter expression is never i32 0.  And a selector with a filter in it is not, in fact, a cleanup-only selector.  So how does this not take filters into account?
> 
> Yup, filters never use 0.
> 
>>> This might not work 100% if there are filters and / or there is a catchall in one or both of the selectors. Basically, the llvm.eh.selector's structure will have to be interpreted for both selectors and reassembled.
>> 
>> 
>> I don't know what filters have to do with it — they're not semantically different from any other "handler", i.e. they can't be re-ordered (please tell me you're not re-ordering filters with respect to catches).  I'm willing to believe that the backend has constraints about whether cleanups can appear redundantly or something like that.
> 
> I'm fairly sure that the code generators don't care where the cleanup is.  If
> they do then they can be fixed.

Okay.  I'm going to go ahead and commit, then, and we can deal with the consequences as they arise.

John.



More information about the llvm-commits mailing list