https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142
--- Comment #2 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 28 Nov 2017, prathamesh3492 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83142 > > prathamesh3492 at gcc dot gnu.org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |prathamesh3492 at gcc dot > gnu.org > > --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- > Hi, > I had submitted a patch for a similar case involving __builtin_memcpy: > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02485.html > > IIUC, there was following issue: > Marking it as tailcall at GIMPLE won't necessarily make it a tail-call during > RTL tail-call emission. To address this issue, the patch created artificial > lhs > and returned that instead for the tail-call to be in more "natural" form: > > _memcpy(dest, src, n) > return dest > to > _1 = memcpy(dest, src, n) > return _1 > > And I think later it was concluded that this was better handled in FRE/PRE, > for > which you had posted a patch: > https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00424.html Yeah, that didn't work out so I implemented the reverse now, postponed for GCC 9 because of this and other fallout. So we should revisit your original patch and adjust it to re-instantiate a LHS on the call & propagate to dominating uses.
