From: David Laight <David.Laight@ACULAB.COM>
To: 'Ivan Orlov' <ivan.orlov0322@gmail.com>,
"paul.walmsley@sifive.com" <paul.walmsley@sifive.com>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>
Cc: "conor.dooley@microchip.com" <conor.dooley@microchip.com>,
"ajones@ventanamicro.com" <ajones@ventanamicro.com>,
"samuel@sholland.org" <samuel@sholland.org>,
"alexghiti@rivosinc.com" <alexghiti@rivosinc.com>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>
Subject: RE: [PATCH] riscv: lib: Optimize 'strlen' function
Date: Sun, 17 Dec 2023 18:10:54 +0000 [thread overview]
Message-ID: <a210197c479e48778672aa13287eef88@AcuMS.aculab.com> (raw)
In-Reply-To: <20231213154530.1970216-1-ivan.orlov0322@gmail.com>
From: Ivan Orlov
> Sent: 13 December 2023 15:46
Looking at the old code...
> 1:
> - lbu t0, 0(t1)
> - beqz t0, 2f
> - addi t1, t1, 1
> - j 1b
I suspect there is (at least) a two clock stall between
the 'ldu' and 'beqz'.
Allowing for one clock for the 'predicted taken' branch
that is 7 clocks/byte.
Try this one - especially on 32bit:
mov t0, a0
and t1, t0, 1
sub t0, t0, t1
bnez t1, 2f
1:
ldb t1, 0(t0)
2: ldb t2, 1(t0)
add t0, t0, 2
beqz t1, 3f
bnez t2, 1b
add t0, t0, 1
3: sub t0, t0, 2
sub a0, t0, a0
ret
Might be 6 clocks for 2 bytes.
The much smaller cache footprint will also help.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-12-17 18:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 15:45 [PATCH] riscv: lib: Optimize 'strlen' function Ivan Orlov
2023-12-17 17:00 ` David Laight
2023-12-17 22:52 ` Ivan Orlov
2023-12-18 1:41 ` Ivan Orlov
2023-12-18 9:20 ` David Laight
2023-12-18 10:03 ` Ivan Orlov
2023-12-18 10:12 ` David Laight
2023-12-17 18:10 ` David Laight [this message]
2023-12-17 23:23 ` Ivan Orlov
2023-12-18 9:12 ` David Laight
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=a210197c479e48778672aa13287eef88@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=ajones@ventanamicro.com \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=conor.dooley@microchip.com \
--cc=ivan.orlov0322@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samuel@sholland.org \
--cc=skhan@linuxfoundation.org \
/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