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.
Richard.
> Honza.
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
