[PATCH] Add movmem optab entry back in for overlapping moves

[Aaron Sawdey <acsawdey@linux.ibm.com>]

This is the second piece for allowing inline expansion of memmove. Now that
the old movmem patterns have all been renamed to cpymem, the movmem optab can
be added back.

Next piece will be: add support for __builtin_memmove() to use the movmem optab and
associated patterns.

This patch passes bootstrap/regtest on ppc64le and x86_64. Ok for trunk?

2019-07-02  Aaron Sawdey  <acsawdey@linux.ibm.com>

	* optabs.def (movmem_optab): Add movmem back for memmove().
	* doc/md.texi: Add description of movmem pattern for overlapping move.


Index: gcc/doc/md.texi
===================================================================
--- gcc/doc/md.texi	(revision 272762)
+++ gcc/doc/md.texi	(working copy)
@@ -6237,6 +6237,42 @@
 overlap. These patterns are used to do inline expansion of
 @code{__builtin_memcpy}.

+@cindex @code{movmem@var{m}} instruction pattern
+@item @samp{movmem@var{m}}
+Block move instruction.  The destination and source blocks of memory
+are the first two operands, and both are @code{mem:BLK}s with an
+address in mode @code{Pmode}.
+
+The number of bytes to copy is the third operand, in mode @var{m}.
+Usually, you specify @code{Pmode} for @var{m}.  However, if you can
+generate better code knowing the range of valid lengths is smaller than
+those representable in a full Pmode pointer, you should provide
+a pattern with a
+mode corresponding to the range of values you can handle efficiently
+(e.g., @code{QImode} for values in the range 0--127; note we avoid numbers
+that appear negative) and also a pattern with @code{Pmode}.
+
+The fourth operand is the known shared alignment of the source and
+destination, in the form of a @code{const_int} rtx.  Thus, if the
+compiler knows that both source and destination are word-aligned,
+it may provide the value 4 for this operand.
+
+Optional operands 5 and 6 specify expected alignment and size of block
+respectively.  The expected alignment differs from alignment in operand 4
+in a way that the blocks are not required to be aligned according to it in
+all cases. This expected alignment is also in bytes, just like operand 4.
+Expected size, when unknown, is set to @code{(const_int -1)}.
+
+Descriptions of multiple @code{movmem@var{m}} patterns can only be
+beneficial if the patterns for smaller modes have fewer restrictions
+on their first, second and fourth operands.  Note that the mode @var{m}
+in @code{movmem@var{m}} does not impose any restriction on the mode of
+individually copied data units in the block.
+
+The @code{movmem@var{m}} patterns must correctly handle the case where
+the source and destination strings overlap. These patterns are used to
+do inline expansion of @code{__builtin_memmove}.
+
 @cindex @code{movstr} instruction pattern
 @item @samp{movstr}
 String copy instruction, with @code{stpcpy} semantics.  Operand 0 is
Index: gcc/optabs.def
===================================================================
--- gcc/optabs.def	(revision 272762)
+++ gcc/optabs.def	(working copy)
@@ -257,6 +257,7 @@
 OPTAB_D (cmpstr_optab, "cmpstr$a")
 OPTAB_D (cmpstrn_optab, "cmpstrn$a")
 OPTAB_D (cpymem_optab, "cpymem$a")
+OPTAB_D (movmem_optab, "movmem$a")
 OPTAB_D (setmem_optab, "setmem$a")
 OPTAB_D (strlen_optab, "strlen$a")


-- 
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