[LLVMdev] Alternative exception handling proposal

[Duncan Sands]

Hi John,

>>> For extra goodness, I propose introducing a new instruction "rewind" that takes
>>> an exception pointer and selector value as arguments:
>>>     rewind<ptr>,<i32>
>>
>> Actually the existing "unwind" instruction can be repurposed for this, as there
>> was no real need for rewind to take any arguments.  All that is needed is that
>> unwind be lowered to a call of eh.exception, which is then passed as the
>> argument to _Unwind_Resume,  In fact codegen already does this!
>
> 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.

> 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.
>
> That is, instead of:
>    rewind i8* %saved_exception_ptr
> you'd have:
>    rewind void @_Unwind_Resume(i8* %saved_exception_ptr)
> or:
>    rewind void @_cxa_end_cleanup()
> or, for targets that want special code sequences for resuming, something like:
>    rewind void @llvm.crazytarget.end_cleanup()
>
> This also handily eliminates the problem of EHPrepare having to calculate data flow
> itself to the rewind instruction.
>
> Since Gabor already made most of the world use CallSite, adding a third
> call-like wouldn't be the end of the world, although I think most operations on calls
> (inlining, etc.) wouldn't apply to rewinds anyway.

I think this is way too complicated.

Ciao, Duncan.