Hi Jakub,
> __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.
Thanks that makes sense, so this change would work fine.
However I think almost all targets are affected by this bug - I tried 4 random
backends and all had code similar to AArch64:
if (crtl->calls_eh_return)
{
rtx sa = EH_RETURN_STACKADJ_RTX;
emit_insn (gen_add3_insn (sp_reg_rtx, sp_reg_rtx, sa));
}
... with sibcall case handled after this...
And no code in <target>_function_ok_for_sibcall to block tailcalls...
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?
Wilco
