public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Christoph Müllner" <christoph.muellner@vrull.eu>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Kito Cheng <kito.cheng@sifive.com>,
	 Jim Wilson <jim.wilson.gcc@gmail.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Andrew Waterman <andrew@sifive.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	 Vineet Gupta <vineetg@rivosinc.com>
Subject: Re: [PATCH 5/7] riscv: Use by-pieces to do overlapping accesses in block_move_straight
Date: Mon, 14 Nov 2022 20:01:35 +0100	[thread overview]
Message-ID: <CAEg0e7hhUwaR=Eu6Qto=3CwzfN9Tzv-cBUV8+CCQwWJBwG3W9Q@mail.gmail.com> (raw)
In-Reply-To: <4975b815-11e5-28ae-2b7b-9d38886119ed@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

On Mon, Nov 14, 2022 at 6:16 PM Jeff Law <jeffreyalaw@gmail.com> wrote:

>
> On 11/13/22 16:05, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@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);
The signature of riscv_block_move_straight wants a "unsigned HOST_WIDE_INT
length".
So we can simply reuse length instead of doing "INTVAL (length)", which is
redundant
and uses the wrong signess (INTVAL vs UINTVAL).

Also, the ChangeLog entry for the test was missing.

Thanks,
Christoph


>
>
> jeff
>
>
>

  reply	other threads:[~2022-11-14 19:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-13 23:05 [PATCH 0/7] riscv: Improve builtins expansion Christoph Muellner
2022-11-13 23:05 ` [PATCH 1/7] riscv: bitmanip: add orc.b as an unspec Christoph Muellner
2022-11-14 16:51   ` Jeff Law
2022-11-14 17:53     ` Jeff Law
2022-11-14 19:05     ` Philipp Tomsich
2022-11-13 23:05 ` [PATCH 2/7] riscv: bitmanip/zbb: Add prefix/postfix and enable visiblity Christoph Muellner
2022-11-14 16:55   ` Jeff Law
2022-11-13 23:05 ` [PATCH 3/7] riscv: Enable overlap-by-pieces via tune param Christoph Muellner
2022-11-14  2:48   ` Vineet Gupta
2022-11-14  7:59     ` Philipp Tomsich
2022-11-14  8:29       ` Christoph Müllner
2022-11-14 19:04         ` Jeff Law
2022-11-14 19:07           ` Christoph Müllner
2022-11-13 23:05 ` [PATCH 4/7] riscv: Move riscv_block_move_loop to separate file Christoph Muellner
2022-11-14 16:56   ` Jeff Law
2022-11-13 23:05 ` [PATCH 5/7] riscv: Use by-pieces to do overlapping accesses in block_move_straight Christoph Muellner
2022-11-14 17:16   ` Jeff Law
2022-11-14 19:01     ` Christoph Müllner [this message]
2022-11-14 19:05       ` Jeff Law
2022-11-13 23:05 ` [PATCH 6/7] riscv: Add support for strlen inline expansion Christoph Muellner
2022-11-14 18:17   ` Jeff Law
2022-11-14 21:07     ` Christoph Müllner
2022-11-13 23:05 ` [PATCH 7/7] riscv: Add support for str(n)cmp " Christoph Muellner
2022-11-14 19:28   ` Jeff Law
2022-11-14 21:49     ` Christoph Müllner
2022-11-15  0:22       ` Jeff Law
2022-11-15  0:46   ` Kito Cheng
2022-11-15  0:53     ` Palmer Dabbelt
2022-11-15  1:55       ` Kito Cheng
2022-11-15  3:41       ` Jeff Law
2022-11-15 22:22     ` Christoph Müllner
2022-11-16  0:15     ` Philipp Tomsich
2022-11-21  3:24       ` Kito Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEg0e7hhUwaR=Eu6Qto=3CwzfN9Tzv-cBUV8+CCQwWJBwG3W9Q@mail.gmail.com' \
    --to=christoph.muellner@vrull.eu \
    --cc=andrew@sifive.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=vineetg@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).