Documentation for movstrM, clrstrM -- more rambling and patch

[Hans-Peter Nilsson]

[ Ok, this movstr documentation issue is not really important.  Just for the
  sake of clearing up the misunderstanding, I guess I'll appear ;-) to be
  nitpicking.  Then ignore this entirely, or at least check the patch. ]

I guess I used the word "mode" confusingly in my previous mail a week ago.
 I meant the "mode" as in the *name* of the pattern; not really the mode of
its operands (although the third operand has this mode).

 The answer from Jeff Law (who's doing a great job on the egcs list) to my
previous mail indicates to me, that this documentation fix is justifiable.

Jeff Law writes in < 7373.884556682@hurl.cygnus.com >,
 <URL: http://www.cygnus.com/ml/egcs/1998-Jan/0285.html >; in response to
< 199801111954.UAA28634@scar.axis.se >,
 <URL: http://www.cygnus.com/ml/egcs/1998-Jan/0282.html >:
> The size of the block has nothing to do with the mode for the movstrsi
> pattern.
As long as the size fits in SImode, yes.

>
> The mode merely indicates the size of the units moved within the hunk.
No, the mode M in the pattern name does not reflect the size of the *units*
within the hunk; the *size of the entire "hunk"* must fit in a mode M.
 The only indication of any "unit size" is the alignment, and it's just a
correlation. 

 To check this for yourself, egrep for "HAVE_movstr(ti|di|si|hi|qi)" in expr.c
(the only place where movstr is actively used).
 Or you could rename the "movstrsi"-pattern for i386 to "movstrqi" (and change
the third operand etc.), and try copying a structure larger than 255 bytes;
the pattern does not match.

 My point is for the documentation to be clear on that "movstrqi" should *not*
be defined instead of "movstrsi" (or larger), if only for the reason that the
instruction moves byte-wise, or needs no specific block alignment, and that
there's normally no use in defining several "movstrM" patterns.  If people
think that's already clear, then sorry about the rambling.


Anyway, it seems like no machine descriptions in the distribution is affected
by any confusion about this, so it's just a documentation issue.

Here's a new patch for the documentation of the "movstr" and "clrstr"
patterns:

Sun Jan 18 18:55:58 1998  Hans-Peter Nilsson  <hp@axis.se>

        * md.texi: Explain use of different M:s in movstrM, clrstrM

*** md.texi.original    Sun Jan 11 14:40:21 1998
--- md.texi     Sun Jan 18 18:55:46 1998
*************** destination, in the form of a @code{cons
*** 1956,1961 ****
--- 1956,1967 ----
  compiler knows that both source and destination are word-aligned,
  it may provide the value 4 for this operand.
  
+ Descriptions of multiple @code{movstr@var{m}} patterns can only be
+ beneficent, if the patterns for smaller @var{m}:s have less restrictions
+ on their first, second and fourth operands.  Note that the @var{m} in
+ @code{movstr@var{m}} does not impose any restriction on the mode of
+ individually moved data units in the block.
+ 
  These patterns need not give special consideration to the possibility
  that the source and destination strings might overlap.
  
*************** The third operand is the known alignment
*** 1969,1974 ****
--- 1975,1982 ----
  of a @code{const_int} rtx.  Thus, if the compiler knows that the
  destination is word-aligned, it may provide the value 4 for this
  operand.
+ 
+ The use for multiple @code{clrstr@var{m}} is as for @code{movstr@var{m}}.
  
  @cindex @code{cmpstr@var{m}} instruction pattern
  @item @samp{cmpstr@var{m}}

Hope to send something of more significant value soon.
Best regards,
-- 
Hans-Peter Nilsson, Axis Communications AB, S - 223 70 LUND, SWEDEN
Hans-Peter.Nilsson@axis.se | http://www.axis.se/ | Tel +46 46191867,191800
Fax +46 46136130 | RFC 1855 compliance implemented; report loss of brain.