From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C46BC71153 for ; Sun, 3 Sep 2023 21:20:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348465AbjICVUK (ORCPT ); Sun, 3 Sep 2023 17:20:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229495AbjICVUJ (ORCPT ); Sun, 3 Sep 2023 17:20:09 -0400 Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4878AAD for ; Sun, 3 Sep 2023 14:20:04 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 383LJga1031746; Sun, 3 Sep 2023 23:19:42 +0200 Date: Sun, 3 Sep 2023 23:19:42 +0200 From: Willy Tarreau To: David Laight Cc: "'Ammar Faizi'" , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Nicholas Rosenberg , Alviro Iskandar Setiawan , Michael William Jonathan , GNU/Weeb Mailing List , Linux Kernel Mailing List Subject: Re: [RFC PATCH v3 0/4] nolibc x86-64 string functions Message-ID: <20230903211942.GA31739@1wt.eu> References: <20230902133505.2176434-1-ammarfaizi2@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 03, 2023 at 08:38:22PM +0000, David Laight wrote: > From: Ammar Faizi > > Sent: 02 September 2023 14:35 > > > > This is an RFC patchset v3 for nolibc x86-64 string functions. > > > > There are 4 patches in this series: > > > > ## Patch 1-2: Use `rep movsb`, `rep stosb` for: > > - memcpy() and memmove() > > - memset() > > respectively. They can simplify the generated ASM code. > > It is worth pointing out that while the code size for 'rep xxxb' > is smaller, the performance is terrible. > The only time it is ever good is for the optimised forwards > copies on cpu that support it. > > reverse, stos and scas are always horrid. It's terrible compared to other approaches but not *that* bad. Also we absolutely don't care about performance here, rather about correctness and compact size. Regards, Willy