This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: problems in interaction between peephole on CALL_INSN and final_scan_insn
On Sun, 8 Jul 2012, Alan Lehotsky wrote:
> I'm certain there are better ways; can you be more specific though?
>
> Or are you just talking about defining a sibcall_epilogue pattern?
I'm not Andrew but I think obviously enough "yes". Better to
say, perhaps even document, that text peepholes are deprecated,
and "fixing" them to work with calls (or jumps) just won't
happen. (Except through curing-headache-by-beheading --
removing them completely).
>
> On Jul 8, 2012, at 5:26 PM, Andrew Pinski wrote:
>
> > On Sun, Jul 8, 2012 at 2:23 PM, Alan Lehotsky <qsmgmt@earthlink.net> wrote:
> >> When a peephole is recognized, the first insn in the group is replaced by a pseudo insn that contains all the referenced operands in the TEMPLATE and sets an INSN_CODE to indicate which peephole matched.
> >>
> >> This is all well and good, except that if the peephole involves a CALL_INSN, final_scan_insn() will invoke call_from_call_insn() to try and get the call RTL. But if the peephole is in fact some kind of a tail call, we no longer have a call expression to be found and end up asserting in call_from_call_insn().
> >
> >
> > Simple answer don't use peephole optimization to perform the tail call
> > optimization. There are better ways of performing that optimization.
> >
> > Thanks,
> > Andrew
>