This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy
- From: Aaron Sawdey <acsawdey at linux dot ibm dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: gcc at gcc dot gnu dot org, Joseph Myers <joseph at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, law at redhat dot com, Segher Boessenkool <segher at kernel dot crashing dot org>, David Edelsohn <dje dot gcc at gmail dot com>, Bill Schmidt <wschmidt at linux dot ibm dot com>
- Date: Wed, 15 May 2019 08:16:23 -0500
- Subject: Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy
- References: <ee8e07d1-1e34-15e9-1536-161c9c29b3e2@linux.ibm.com> <alpine.LSU.2.21.1905151302540.8064@wotan.suse.de>
On 5/15/19 8:10 AM, Michael Matz wrote:> On Tue, 14 May 2019, Aaron Sawdey wrote:
>
>> memcpy -> expand with movmem pattern
>> memmove (no overlap) -> transform to memcpy -> expand with movmem pattern
>> memmove (overlap) -> remains memmove -> glibc call
> ...
>> However in builtins.c expand_builtin_memmove() does not actually do the
>> expansion using the memmove pattern.
>
> Because it can't: the movmem pattern is not defined to require handling
> overlaps, and hence can't be used for any possibly overlapping
> memmove. (So, in a way the pattern is misnamed and should probably have
> been called cpymem from the beginning, alas there we are).
>
>> So here's my proposed set of fixes:
>> * Add new optab entries for nonoverlapping_memcpy and overlapping_memmove
>> cases.
>
> Wouldn't it be nicer to rename the current movmem pattern to cpymem
> wholesale for all ports (i.e. roughly a big s/movmem/cpymem/ over the
> whole tree) and then introduce a new optional movmem pattern with
> overlapping semantics?
Yeah that makes a lot of sense. I was unaware of that history, and was led
astray by the fact that the powerpc implementation of movemem works by
doing a bunch of loads into registers followed by a bunch of stores and
so (I think) would actually work for the overlap case.
Thanks,
Aaron
--
Aaron Sawdey, Ph.D. acsawdey@linux.vnet.ibm.com
050-2/C113 (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain