> The code will do:
> size = convert_to_mode (cmp_mode, size, 1);
> i.e. convert size from whatever mode it had before to cmp_mode and the
> test is whether it can do so without changing the behavior. If size is
> non-constant, then that can be obviously (without using range info etc.)
> done only if the original mode is narrower or at most as wide as cmp_mode.
> We could do the same for CONST_INT_P too, but as we know the constant,
> it wants to make sure that the size can be expressed in cmp_mode.
> As it is unsigned quantity, that can be checked by checking if the value is
> <= GET_MODE_MASK.
That's one interpretationn, the other being that of emit_block_move_via_movmem
and the latter looks sensible to me too: if the top bit is set, the conversion
will yield a negative RTL constant which will be sent to the target pattern,
which could not be prepared for such a negative constant:
`movmemM'
Block move instruction. The destination and source blocks of
memory are the first two operands, and both are `mem:BLK's with an
address in mode `Pmode'.
The number of bytes to move is the third operand, in mode M.
Usually, you specify `Pmode' for 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., `QImode' for values in the range 0-127;
note we avoid numbers that appear negative) and also a pattern
with `Pmode'.
That being said, your patch doesn't change the interpretation so is OK.
--
Eric Botcazou
