On Thu, 12 Sep 2019, Bernd Edlinger wrote: > On 9/12/19 10:08 AM, Richard Biener wrote: > > On Wed, 11 Sep 2019, Bernd Edlinger wrote: > > > >> On 9/11/19 8:30 PM, Richard Biener wrote: > > > > More like the following? I wonder if we can assert that > > MEM_NOTRAP_P () are equal (see all the for_gcse checks in exp_equiv_p). > > But as said earlier I wonder in which cases a replacement is > > profitable at all - thus, if a > > > > else if (MEM_P (trial)) > > /* Do not replace anything with a MEM. */ > > ; > > > > Yes, I like that better, since there is essentially nothing stopping > it from replacing a REG with a MEM, except the rtxcost function, maybe. > > It turned out that the previous version got into an endless loop here, > since the loop termination happens when replacing MEM by itself, except > when something else terminates the search.
Is that how it works without the patch as well? I admit the loop is a bit hard to follow since it is not only iterating over elt->next_same_value ... > So how about this? > > The only possible MEM->MEM transformations are now: > - replacing trial = dest (result mov dest, dest; which is a no-op insn) > - replacing trial = src (which is a no-op transformation, and exits the loop) > > Therefore the overlapping mem move handling no longer necessary. > > > Bootstrap and reg-tested on x86_64-pc-linux-gnu. > Is it OK for trunk? Looks OK to me. Can you see if this has any unexpected code-generation effects? I would expect it to not make a difference at all, but you never know -- any differences in cc1files? Not really my primary area of expertise... Thanks, Richard.
