public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Add movmem optab entry back in for overlapping moves
@ 2019-07-02 14:33 Aaron Sawdey
  2019-07-02 17:45 ` Jeff Law
  0 siblings, 1 reply; 2+ messages in thread
From: Aaron Sawdey @ 2019-07-02 14:33 UTC (permalink / raw)
  To: gcc-patches
  Cc: Segher Boessenkool, Bill Schmidt, David Edelsohn, rguenther,
	Jakub Jelinek, Jeff Law

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Add movmem optab entry back in for overlapping moves
  2019-07-02 14:33 [PATCH] Add movmem optab entry back in for overlapping moves Aaron Sawdey
@ 2019-07-02 17:45 ` Jeff Law
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Law @ 2019-07-02 17:45 UTC (permalink / raw)
  To: Aaron Sawdey, gcc-patches
  Cc: Segher Boessenkool, Bill Schmidt, David Edelsohn, rguenther,
	Jakub Jelinek

On 7/2/19 8:32 AM, Aaron Sawdey wrote:
> 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.
OK
jeff

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-07-02 17:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-02 14:33 [PATCH] Add movmem optab entry back in for overlapping moves Aaron Sawdey
2019-07-02 17:45 ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).