From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7767A481BE for ; Sun, 17 Dec 2023 18:11:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aculab.com Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mtapsc-8-8i7rSkpZMKS305nSrnFEhQ-1; Sun, 17 Dec 2023 18:11:13 +0000 X-MC-Unique: 8i7rSkpZMKS305nSrnFEhQ-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Sun, 17 Dec 2023 18:10:54 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Sun, 17 Dec 2023 18:10:54 +0000 From: David Laight To: 'Ivan Orlov' , "paul.walmsley@sifive.com" , "palmer@dabbelt.com" , "aou@eecs.berkeley.edu" CC: "conor.dooley@microchip.com" , "ajones@ventanamicro.com" , "samuel@sholland.org" , "alexghiti@rivosinc.com" , "linux-riscv@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "skhan@linuxfoundation.org" Subject: RE: [PATCH] riscv: lib: Optimize 'strlen' function Thread-Topic: [PATCH] riscv: lib: Optimize 'strlen' function Thread-Index: AQHaLduBo9lhsHug1EOTPi9OJpSM+LCtyBWA Date: Sun, 17 Dec 2023 18:10:54 +0000 Message-ID: References: <20231213154530.1970216-1-ivan.orlov0322@gmail.com> In-Reply-To: <20231213154530.1970216-1-ivan.orlov0322@gmail.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Ivan Orlov > Sent: 13 December 2023 15:46 Looking at the old code... > 1: > -=09lbu=09t0, 0(t1) > -=09beqz=09t0, 2f > -=09addi=09t1, t1, 1 > -=09j=091b 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: =09mov=09t0, a0 =09and=09t1, t0, 1 =09sub=09t0, t0, t1 =09bnez=09t1, 2f 1: =09ldb=09t1, 0(t0) 2:=09ldb=09t2, 1(t0) =09add=09t0, t0, 2 =09beqz=09t1, 3f =09bnez=09t2, 1b =09add=09t0, t0, 1 3:=09sub=09t0, t0, 2 =09sub=09a0, t0, a0 =09ret Might be 6 clocks for 2 bytes. The much smaller cache footprint will also help. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)