https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78847
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #1)
> Not sure what the best angle is here.
>
> _18 = (unsigned long) &MEM[(void *)&foo + 9B];
> _16 = _18 + 1;
>
> looks like it would be better as:
>
> _19 = (unsigned long) &foo;
> _16 = _19 + 10;
>
> (I guess we don't want to produce &MEM[(void *)&foo + 10B])
>
> But that might not be true anymore if _18 had several uses.
We do already have
/* Pattern match
tem1 = (long) ptr1;
tem2 = (long) ptr2;
tem3 = tem2 - tem1;
tem4 = (unsigned long) tem3;
tem5 = ptr1 + tem4;
and produce
tem5 = ptr2; */
(simplify
(pointer_plus @0 (convert?@2 (minus@3 (convert @1) (convert @0))))
/* Conditionally look through a sign-changing conversion. */
(if (TYPE_PRECISION (TREE_TYPE (@2)) == TYPE_PRECISION (TREE_TYPE (@3))
&& ((GIMPLE && useless_type_conversion_p (type, TREE_TYPE (@1)))
|| (GENERIC && type == TREE_TYPE (@1))))
@1))
for example... But I guess the issue is &MEM[&foo + 9B] vs. &foo.ascii_
(I'm quite sure operand_equal_p doesn't treat those as equal). At least
propagation passes will canonicalize &foo.ascii_ + 1 to &MEM[&foo + 9B]
(but that transform is not done on its own AFAIR). forwprop does that
as well, but not as part of its "copy" lattice init. Fixing that
results in
<bb 2> [10.00%]:
_18 = (unsigned long) &MEM[(void *)&foo + 9B];
_3 = (unsigned long) &MEM[(void *)&foo + 1B];
_16 = _18 + 1;
_14 = _16 - _3;
_13 = buf__9(D) + ptr_6(D);
__builtin_memcpy (_13, &foo, _14);
after forwprop4, so we still miss some patterns here. I guess reassoc
makes our job harder in this case... disabling reassoc2 yields
<bb 2> [10.00%]:
_13 = buf__9(D) + ptr_6(D);
MEM[(char * {ref-all})_13] = MEM[(char * {ref-all})&foo];
return;
at forwprop4. So eventually reassoc misses the &MEM trick as well or we
should really apply that generally (ISTR it messed up some object-size
warning stuff if done generally).
> Reassoc could also play a role, either to cancel the two +1, or to put the
> two converted addresses together.
>
> I guess extra match.pd patterns might be doable as well, but I am scared of
> the number of variants that might appear.
