On Fri, May 10, 2019 at 01:46:07PM +0000, Wilco Dijkstra wrote:
> > So given this and the fact there is no real gain from emitting tailcalls in
> > eh_return
> > functions, wouldn't it make more sense to always block tailcalls in the
> > mid-end?
>
> > No. E.g. x86 handles that just fine,
>
> That's great to hear, but all the other targets still need to be fixed
> somehow.
Not all other targets, just some. I don't see what you find wrong on
actually fixing them. The tail call in that spot is actually very
desirable, but only if we can do a shrink wrapping for it, by doing
if (exc->private)
tail_call _Unwind_RaiseException (exc);
prologue;
whatever;
eh_epilogue;
Or
if (exc->private)
tail_call _Unwind_RaiseException (exc);
else
tail_call _Unwind_Resume (exc);
Except that _Unwind_Resume returns void and is (determined by the compiler)
noreturn, so it doesn't matter what we return. That second option would be
shortest, but we don't have ways to convince the compiler to do that right
now (__attribute__((noipa)) on _Unwind_Resume perhaps, so that it doesn't
tell callers it is noreturn, but the mismatch of the return value is bad.
If you want just ignore the problem, we can just
--- libgcc/unwind.inc.jj 2019-01-01 12:38:17.345987416 +0100
+++ libgcc/unwind.inc 2019-05-10 16:12:18.330555718 +0200
@@ -252,6 +252,7 @@ _Unwind_Resume (struct _Unwind_Exception
a normal exception that was handled. */
_Unwind_Reason_Code LIBGCC2_UNWIND_ATTRIBUTE
+__attribute__((optimize ("no-omit-sibling-calls")))
_Unwind_Resume_or_Rethrow (struct _Unwind_Exception *exc)
{
struct _Unwind_Context this_context, cur_context;
and be done with that.
Jakub
