>
> On 10/27/20 3:01 AM, Richard Biener wrote:
> > On Tue, 27 Oct 2020, Jan Hubicka wrote:
> >
> >>> On Mon, 26 Oct 2020, Jan Hubicka wrote:
> >>>
> >>>> Hi,
> >>>> while looking for special cases of buitins I noticed that tree-ssa-ccp
> >>>> can use EAF_RETURNS_ARG. I wonder if same should be done by value
> >>>> numbering and other propagators....
> >>> The issue is that changing
> >>>
> >>> q = memcpy (p, r);
> >>> .. use q ...
> >>>
> >>> to
> >>>
> >>> memcpy (p, r);
> >>> .. use p ..
> >>>
> >>> is bad for RA so we generally do not want to copy-propagate
> >>> EAF_RETURNS_ARG. We eventually do want to optimize a following
> >>>
> >>>
> >>> if (q == p)
> >>>
> >>> of course. And we eventually want to do the _reverse_ transform,
> >>> replacing
> >>>
> >>> memcpy (p, r)
> >>> .. use p ..
> >>>
> >>> with
> >>>
> >>> tem = memcpy (p, r)
> >>> .. use tem ..
> >>>
> >>> ISTR playing with patches doing all of the above, would need to dig
> >>> them out again. There's also a PR about this I think.
> >>>
> >>> Bernd added some code to RTL call expansion, not sure exactly
> >>> what it does...
> >> It adds copy intstruction to call fusage, so RTL backend now about the
> >> equivalence.
> >> void *
> >> test(void *a, void *b, int l)
> >> {
> >> __builtin_memcpy (a,b,l);
> >> return a;
> >> }
> >> eliminates the extra copy. So I would say that we should not be affraid
> >> to propagate in gimple world. It is a minor thing I guess though.
> >> (my interest is mostly to get rid of unnecesary special casing of
> >> builtins, as these special cases are clearly not well maintained
> >> because almost no one knows about them:)
> > The complication is when this appears in a loop like
> >
> > for (; n; --n)
> > {
> > p = memcpy (p, s, k);
> > p += j;
> > }
> >
> > then I assume IVOPTs can do a better job knowing the equivalence
> > (guess we'd still need to teach SCEV about this then ...) and
> > when it's not present explicitely in the SSA chain any SSA based
> > analysis has difficulties seeing it.
> >
> > ISTR I saw regressions when doing a patch propagating those
> > equivalences.
>
> SImilarly. I don't remember the details, but definitely remember being
> surprised that the propagation caused regressions and then chasing it
> down to a bad interaction with the register allocator.
I wonder if it was before or after the code in calls.c adding
CALL_FUSAGE was added. It is probably not that important, but given
that we have all infrastructure on place it seems pity to not use it.
Honza
>
>
> jeff
>
>
