* Check in merge from gcc2. See ChangeLog.11 and ChangeLog.12

        for details.

        * haifa-sched.c: Mirror recent changes from gcc2.

From-SVN: r18984

1 files changed, 9 insertions, 1 deletions

diff --git a/gcc/md.texi b/gcc/md.texi
index 8ac4d10..e9d4e83 100644
--- a/gcc/md.texi
+++ b/gcc/md.texi
@@ -1949,7 +1949,14 @@ The @samp{cmp@var{m}} patterns should be used instead.
 @item @samp{movstr@var{m}}
 Block move instruction.  The addresses of the destination and source
 strings are the first two operands, and both are in mode @code{Pmode}.
+
 The number of bytes to move is the third operand, in mode @var{m}.
+Usually, you specify @code{word_mode} for @var{m}.  However, if you can
+generate better code knowing the range of valid lengths is smaller than
+those representable in a full word, 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{word_mode}.
 
 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
@@ -1969,7 +1976,8 @@ that the source and destination strings might overlap.
 @item @samp{clrstr@var{m}}
 Block clear instruction.  The addresses of the destination string is the
 first operand, in mode @code{Pmode}.  The number of bytes to clear is
-the second operand, in mode @var{m}.
+the second operand, in mode @var{m}.  See @samp{movstr@var{m}} for
+a discussion of the choice of mode.
 
 The third operand is the known alignment of the destination, in the form
 of a @code{const_int} rtx.  Thus, if the compiler knows that the