On Fri, May 10, 2019 at 10:25:58AM +0000, Wilco Dijkstra wrote:
> Hi Jakub,
>
> 27ec: 912143ff add sp, sp, #0x850
> 27f0: 8b2463ff add sp, sp, x4
> 27f4: 14000000 b 23c8 <_Unwind_RaiseException>
>
> > This does a lot of register saving and restoring, which is not needed but is
> > not wrong-code (guess separate shrink wrapping would help here if
> > implemented for the target). The only wrong-code is actually the
> > add sp, sp, x4 instruction though. The previous instruction restored sp to
> > the value it had at the start of the function and then we should just tail
> > call. This instruction is something that is needed in the spot where
> > __builtin_eh_return is emitted.
>
> The issue seems to be that x4 isn't initialized correctly for tailcalls.
> However
> doesn't that mean tailcalls will ignore __builtin_eh_return? Or does the
> midend
> block any tailcalls that are reachable from __builtin_eh_return?
__builtin_eh_return is a noreturn call, and we never tail call optimize
noreturn calls:
if (flags & ECF_NORETURN)
{
maybe_complain_about_tail_call (exp, "callee does not return");
return false;
}
As both the __builtin_eh_return and other tail calls are points in the CFG
that are followed by EXIT only, it doesn't make sense to talk about
tailcalls ignoring __builtin_eh_return. The tailcall is in one epilogue in
the function, __builtin_eh_return is in another epilogue. We do want that
add sp, sp, x4 in the eh return epilogue, not in the tail call epilogue.
Jakub
