On 11/14/22 12:01, Christoph Müllner wrote:
On Mon, Nov 14, 2022 at 6:16 PM Jeff Law <jeffreya...@gmail.com> wrote:
On 11/13/22 16:05, Christoph Muellner wrote:
> From: Christoph Müllner <christoph.muell...@vrull.eu>
>
> The current implementation of riscv_block_move_straight() emits
a couple
> of load-store pairs with maximum width (e.g. 8-byte for RV64).
> The remainder is handed over to move_by_pieces(), which emits
code based
> target settings like slow_unaligned_access and overlap_op_by_pieces.
>
> move_by_pieces() will emit overlapping memory accesses with maximum
> width only if the given length exceeds the size of one access
> (e.g. 15-bytes for 8-byte accesses).
>
> This patch changes the implementation of riscv_block_move_straight()
> such, that it preserves a remainder within the interval
> [delta..2*delta) instead of [0..delta), so that overlapping memory
> access may be emitted (if the requirements for them are given).
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-string.c (riscv_block_move_straight):
> Adjust range for emitted load/store pairs.
The change to riscv_expand_block_move isn't noted in the
ChangeLog. OK
with that fixed (I'm assuming you want to attempt to use overlapping
word ops for that case).
The change in riscv_expand_block_move is a code cleanup.
At the beginning of riscv_expand_block_move we do the following:
unsigned HOST_WIDE_INT length = UINTVAL (length);
AH, missed that.
Thanks,
Jeff
