https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 29 Jul 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354 > > --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > We have indeed: > # DEBUG D#2 => MEM[(double *)&<retval>] > and on the caller side: > D.2566[_9] = foo<3, 3> (D.2559, D.2572); [return slot optimization] > So, that is why to &<retval> &D.2566[_9] is propagated. > Now, if I add to foo a call to some function template that takes &t as > argument, this is handled correctly because id->regimplify is set to true and > the > qux<C<3> > (&D.2572[_9]); > call is fixed up by gimple_regimplify_operands. That function really isn't > called on debug stmts though (and not prepared to be called for them). > If I use > template <int N, int M> C<N> foo (D<N>, C<M>) { C<N> t; double d = 1.25; > __builtin_memcpy (&t, &d, sizeof (double)); return t; } > instead so that before that inlining we get > MEM <long unsigned int> [(char * {ref-all})&<retval>] = _4; > then it is indeed again gimple_regimplify_operands that fixes up the > MEM <long unsigned int> [(char * {ref-all})&D.2569[_9]] = 4608308318706860032; > into: > _21 = &D.2569[_9]; > MEM <long unsigned int> [(char * {ref-all})_21] = 4608308318706860032; So we could avoid (some) regimplification if we'd dealt with this gimplification step during return value setup. We then only might not re-propagate things and so <retval>.b; might be forever tem_1 = &D.123[j_3]; MEM[tem_1].b; instead of D.123[j_3].b; doing the re-gimplification when we replace things from the decl map might be possible as well of course (and we then would have "context" and could do special things when in ADDR_EXPR context). Not sure how ugly that is. Not sure how bad the non-propagation above is either and how often it triggers.
