https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69246
--- Comment #8 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to rsand...@gcc.gnu.org from comment #7)
> I think the problem with the old code was that we were using
> a non-sibcall expander for an ECF_SIBCALL call. I.e. we generated
> an insn that had the stack adjustment, was marked SIBLING_CALL_P,
> and matched *sibcall_pop, but we generated it through call_pop
> rather than (the nonexistent) sibcall_pop.
>
> Perhaps I should instead have kept the calls.c support for
> sibcall_pop and sibcall_value_pop and defined corresponding
> expanders for x86.
Hmm, now I'm not so sure. Defining and using sibcall(_value)_pop
does fix the bug, but it prevents the frame pointer from being
eliminated, whereas call_pop exists for precisely the opposite
reason:
For machines where @code{RETURN_POPS_ARGS} can be nonzero, the use of these
patterns increases the number of functions for which the frame pointer
can be eliminated, if desired.
So with current trunk we get a plain jump:
foo:
jmp *a
whereas using *sibcall(_value)_pop gives:
foo:
pushl %ebp
movl %esp, %ebp
leave
jmp *a
(like the pre-patch compiler). So maybe we should go with Segher's patch
and delete the *sibcall(_value)_pop patterns?
