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

[Duncan Sands]

Hi,

>> 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.

> 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.

Ciao, Duncan.