[LLVMdev] Alternative exception handling proposal

[Duncan Sands]

Hi John,

>>> I'm unhappy about how this bakes _Unwind_Resume into the backend, particularly
>>> since that prevents us from using better alternatives when they're available
>>> (e.g. the ARM EH ABI's _cxa_end_cleanup(), which saves code size by not requiring
>>> the exception pointer, but which we can only use if we're linking in the C++
>>> standard
>>> library).
>>
>> the code generators can lower "unwind" to a call to _cxa_end_cleanup on that
>> platform.
>
> No, they can't, it's language-library-specific. Only the frontend knows whether
> it's safe to
> introduce that dependency.

I guess the front-end can pass an option to the code generators to select the
desired form.

> Also, _Unwind_Resume has a slightly different name in ARM sjlj EH; it would be great
> if codegen didn't have to hard-code all this again.

If it was all in codegen then front-ends wouldn't have to have this logic.

>>> One idea that comes to mind is that we could make Yet Another call-like
>>> instruction,
>>> a terminator like 'invoke' but with no successors and with the special
>>> replaced-with-a-branch behavior when inlined through an invoke. So the front-end
>>> could call whatever function it pleases, taking responsibility for passing in
>>> the right
>>> information.
>>
>> I think this is way too complicated.
>
> Then instead of using a call, it can be a special kind of unconditional branch which
> the inliner rewrites into a normal branch; that would look exactly like your
> "rewind"
> instruction except for having a successor.

Another possibility is to have front-ends output the desired library call, and
stick an attribute "rewinds" on the call, which tells the optimizers that an
invoke of this call is equivalent to a branch.

Ciao, Duncan.