diff mbox series

[31/30] Update documentation for movmem to cpymem change

Message ID 71f0d015-7b96-0dbf-8776-1a1559902bb9@linux.ibm.com
State New
Headers show
Series Rename movmem pattern to cpymem | expand

Commit Message

Aaron Sawdey June 26, 2019, 8:16 p.m. UTC 
On 6/25/19 4:43 PM, Jeff Law wrote:
> On 6/25/19 2:22 PM, acsawdey@linux.ibm.com wrote:
>> From: Aaron Sawdey <acsawdey@linux.ibm.com>
>>
>> 	* builtins.c (get_memory_rtx): Fix comment.
>> 	* optabs.def (movmem_optab): Change to cpymem_optab.
>> 	* expr.c (emit_block_move_via_cpymem): Change movmem to cpymem.
>> 	(emit_block_move_hints): Change movmem to cpymem.
>> 	* defaults.h: Change movmem to cpymem.
>> 	* targhooks.c (get_move_ratio): Change movmem to cpymem.
>> 	(default_use_by_pieces_infrastructure_p): Ditto.
> So I think you're missing an update to the RTL/MD documentation.  This
> is also likely to cause problems for any out-of-tree ports, so it's
> probably worth a mention in the gcc-10 changes, which will need to be
> created (in CVS no less, ugh).
> 
> I think the stuff posted to-date is fine, but it shouldn't go in without
> the corresponding docs and gcc-10 changes updates.
This would be my proposed patch to update the documentation. I'll also work
out what the entry in the gcc 10 changes and post that for review before
this all goes in.

OK for trunk along with the other 30 patches?

Thanks,
    Aaron



	* doc/md.texi: Change movmem to cpymem and update description to match.
	* doc/rtl.texi: Change movmem to cpymem.
	* target.def (use_by_pieces_infrastructure_p): Change movmem to cpymem.
        * doc/tm.texi: Regenerate.
---
 gcc/doc/md.texi  | 26 ++++++++++++++------------
 gcc/doc/rtl.texi |  2 +-
 gcc/doc/tm.texi  |  4 ++--
 gcc/target.def   |  4 ++--
 4 files changed, 19 insertions(+), 17 deletions(-)

Comments

Jeff Law June 26, 2019, 10:05 p.m. UTC | #1 
On 6/26/19 2:16 PM, Aaron Sawdey wrote:
> On 6/25/19 4:43 PM, Jeff Law wrote:
>> On 6/25/19 2:22 PM, acsawdey@linux.ibm.com wrote:
>>> From: Aaron Sawdey <acsawdey@linux.ibm.com>
>>>
>>> 	* builtins.c (get_memory_rtx): Fix comment.
>>> 	* optabs.def (movmem_optab): Change to cpymem_optab.
>>> 	* expr.c (emit_block_move_via_cpymem): Change movmem to cpymem.
>>> 	(emit_block_move_hints): Change movmem to cpymem.
>>> 	* defaults.h: Change movmem to cpymem.
>>> 	* targhooks.c (get_move_ratio): Change movmem to cpymem.
>>> 	(default_use_by_pieces_infrastructure_p): Ditto.
>> So I think you're missing an update to the RTL/MD documentation.  This
>> is also likely to cause problems for any out-of-tree ports, so it's
>> probably worth a mention in the gcc-10 changes, which will need to be
>> created (in CVS no less, ugh).
>>
>> I think the stuff posted to-date is fine, but it shouldn't go in without
>> the corresponding docs and gcc-10 changes updates.
> This would be my proposed patch to update the documentation. I'll also work
> out what the entry in the gcc 10 changes and post that for review before
> this all goes in.
> 
> OK for trunk along with the other 30 patches?
> 
> Thanks,
>     Aaron
> 
> 
> 
> 	* doc/md.texi: Change movmem to cpymem and update description to match.
> 	* doc/rtl.texi: Change movmem to cpymem.
> 	* target.def (use_by_pieces_infrastructure_p): Change movmem to cpymem.
>         * doc/tm.texi: Regenerate.
OK.  The entire kit is OK for the trunk now.

jeff
diff mbox series

Patch

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index b45b4be..3f9d545 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -6200,13 +6200,13 @@  This pattern is not allowed to @code{FAIL}.
 @item @samp{one_cmpl@var{m}2}
 Store the bitwise-complement of operand 1 into operand 0.

-@cindex @code{movmem@var{m}} instruction pattern
-@item @samp{movmem@var{m}}
-Block move instruction.  The destination and source blocks of memory
+@cindex @code{cpymem@var{m}} instruction pattern
+@item @samp{cpymem@var{m}}
+Block copy 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 move is the third operand, in mode @var{m}.
+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
@@ -6226,14 +6226,16 @@  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
+Descriptions of multiple @code{cpymem@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 moved data units in the block.
+in @code{cpymem@var{m}} does not impose any restriction on the mode of
+individually copied data units in the block.

-These patterns need not give special consideration to the possibility
-that the source and destination strings might overlap.
+The @code{cpymem@var{m}} patterns need not give special consideration
+to the possibility that the source and destination strings might
+overlap. These patterns are used to do inline expansion of
+@code{__builtin_memcpy}.

 @cindex @code{movstr} instruction pattern
 @item @samp{movstr}
@@ -6254,7 +6256,7 @@  given as a @code{mem:BLK} whose address is in mode @code{Pmode}.  The
 number of bytes to set is the second operand, in mode @var{m}.  The value to
 initialize the memory with is the third operand. Targets that only support the
 clearing of memory should reject any value that is not the constant 0.  See
-@samp{movmem@var{m}} for a discussion of the choice of mode.
+@samp{cpymem@var{m}} for a discussion of the choice of mode.

 The fourth operand is the known alignment of the destination, in the form
 of a @code{const_int} rtx.  Thus, if the compiler knows that the
@@ -6272,13 +6274,13 @@  Operand 9 is the probable maximal size (i.e.@: we cannot rely on it for
 correctness, but it can be used for choosing proper code sequence for a
 given size).

-The use for multiple @code{setmem@var{m}} is as for @code{movmem@var{m}}.
+The use for multiple @code{setmem@var{m}} is as for @code{cpymem@var{m}}.

 @cindex @code{cmpstrn@var{m}} instruction pattern
 @item @samp{cmpstrn@var{m}}
 String compare instruction, with five operands.  Operand 0 is the output;
 it has mode @var{m}.  The remaining four operands are like the operands
-of @samp{movmem@var{m}}.  The two memory blocks specified are compared
+of @samp{cpymem@var{m}}.  The two memory blocks specified are compared
 byte by byte in lexicographic order starting at the beginning of each
 string.  The instruction is not allowed to prefetch more than one byte
 at a time since either string may end in the first byte and reading past
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index f5f2de7..0814b66 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -3341,7 +3341,7 @@  that the register is live.  You should think twice before adding
 instead.  The @code{use} RTX is most commonly useful to describe that
 a fixed register is implicitly used in an insn.  It is also safe to use
 in patterns where the compiler knows for other reasons that the result
-of the whole pattern is variable, such as @samp{movmem@var{m}} or
+of the whole pattern is variable, such as @samp{cpymem@var{m}} or
 @samp{call} patterns.

 During the reload phase, an insn that has a @code{use} as pattern
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index c2aa4d0..14c1ea6 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6661,7 +6661,7 @@  two areas of memory, or to set, clear or store to memory, for example
 when copying a @code{struct}. The @code{by_pieces} infrastructure
 implements such memory operations as a sequence of load, store or move
 insns.  Alternate strategies are to expand the
-@code{movmem} or @code{setmem} optabs, to emit a library call, or to emit
+@code{cpymem} or @code{setmem} optabs, to emit a library call, or to emit
 unit-by-unit, loop-based operations.

 This target hook should return true if, for a memory operation with a
@@ -6680,7 +6680,7 @@  optimized for speed rather than size.

 Returning true for higher values of @var{size} can improve code generation
 for speed if the target does not provide an implementation of the
-@code{movmem} or @code{setmem} standard names, if the @code{movmem} or
+@code{cpymem} or @code{setmem} standard names, if the @code{cpymem} or
 @code{setmem} implementation would be more expensive than a sequence of
 insns, or if the overhead of a library call would dominate that of
 the body of the memory operation.
diff --git a/gcc/target.def b/gcc/target.def
index 71b6972..4165405 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -3531,7 +3531,7 @@  two areas of memory, or to set, clear or store to memory, for example\n\
 when copying a @code{struct}. The @code{by_pieces} infrastructure\n\
 implements such memory operations as a sequence of load, store or move\n\
 insns.  Alternate strategies are to expand the\n\
-@code{movmem} or @code{setmem} optabs, to emit a library call, or to emit\n\
+@code{cpymem} or @code{setmem} optabs, to emit a library call, or to emit\n\
 unit-by-unit, loop-based operations.\n\
 \n\
 This target hook should return true if, for a memory operation with a\n\
@@ -3550,7 +3550,7 @@  optimized for speed rather than size.\n\
 \n\
 Returning true for higher values of @var{size} can improve code generation\n\
 for speed if the target does not provide an implementation of the\n\
-@code{movmem} or @code{setmem} standard names, if the @code{movmem} or\n\
+@code{cpymem} or @code{setmem} standard names, if the @code{cpymem} or\n\
 @code{setmem} implementation would be more expensive than a sequence of\n\
 insns, or if the overhead of a library call would dominate that of\n\
 the body of the memory operation.\n\