From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id DFDBF3858D37 for ; Mon, 9 Jan 2023 20:59:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFDBF3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62e.google.com with SMTP id jo4so23385642ejb.7 for ; Mon, 09 Jan 2023 12:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8qwRChnxQFQ07Vx1QC92XQPtMFAjZT8lnZJQnef8muI=; b=l0Gs0nikGCUN14uO7GrB/SWnkH4RWVLbzAOEyHzMu9YcNa9Ofc/W9Zcm4qp/wgM2j9 7+T0kZTBr8gnYG4d8h8H++FojEtVSnK6extHMnllQX97Gn/l+gvVuFEgk5q7VlbF1DKt QzaYRuOSrDFVe0fwy5eXWyUb731JpnAtY7c3i8OydRWuFxcMIUDLFdM7ksWToBlRC8Sa kz81C+FWWR+hQcrKGdLxkll8OQNHX4gr946AmSsqNV1zYDy5cz5OJhB0npK0UiOl1ex3 WN1bVY9QdSUkmc7ubal2FGQMnBynKsbG76qvMUGXBi6e4VHz0dKZXxG92yyayAHo9umJ 315Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8qwRChnxQFQ07Vx1QC92XQPtMFAjZT8lnZJQnef8muI=; b=NsSvk7OCYwKA9Ys1nedit7Y67XaHahNd+ny1w5HXuKDxxqtP5k5ssALi1ibT2/LZ5g jRILIcBegm71j1Wku/oOwOb0SGmcYd0MbeBiUbBrNDOMJoOl/Cau1+nQ+V1zb/94GXrF oKKuhP58M73J5ybOEa0ECC38C8cJE9zK6yaxnwnkCmJrXUmKUQpQB54UZvs7rM/Os4QN Gx/fuFW1JZQGGgy/xIjb2E8LHpQuQhhSEF9ZkYzntbHXW6Uy9WDdQ9rvbyoImwPqLqFx /83IbnWsj5FSe/wRruY8FZxVAXgpP7Ffd9IH37owr5RSkShrMyiUM1lUiAYhxqPis2HT MSzg== X-Gm-Message-State: AFqh2kqkNlPkXOzxyZHtnMfH6nO697+XOVdDENYD3qIEsHq8y9SzK6DY g1dDvJyIWqHRkzDahGfVjCmX0X5xrbs8+lXw7IfLs/tyau4= X-Google-Smtp-Source: AMrXdXt1V4SScdySsSJgHUjV/5WPU0PwUdh0uawWPywsG8jg3FRyHb32FVI4lIc+dshFVi6CHnkqTClHkHtz0eiALY4= X-Received: by 2002:a17:906:2bce:b0:84c:c4a4:bd4 with SMTP id n14-20020a1709062bce00b0084cc4a40bd4mr1646016ejg.645.1673297980585; Mon, 09 Jan 2023 12:59:40 -0800 (PST) MIME-Version: 1.0 References: <20220919195920.956393-1-adhemerval.zanella@linaro.org> <20220919195920.956393-9-adhemerval.zanella@linaro.org> In-Reply-To: From: Noah Goldstein Date: Mon, 9 Jan 2023 12:59:29 -0800 Message-ID: Subject: Re: [PATCH v5 08/17] string: Improve generic strchrnul To: Adhemerval Zanella Netto Cc: libc-alpha@sourceware.org, Richard Henderson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Jan 9, 2023 at 12:35 PM Adhemerval Zanella Netto wrote: > > > > On 05/01/23 20:17, Noah Goldstein wrote: > > On Mon, Sep 19, 2022 at 1:04 PM Adhemerval Zanella via Libc-alpha > > wrote: > >> > >> New algorithm have the following key differences: > >> > >> - Reads first word unaligned and use string-maskoff function to > >> remove unwanted data. This strategy follow arch-specific > >> optimization used on aarch64 and powerpc. > >> > >> - Use string-fz{b,i} functions. > >> > >> Checked on x86_64-linux-gnu, i686-linux-gnu, powerpc64-linux-gnu, > >> and powerpc-linux-gnu by removing the arch-specific assembly > >> implementation and disabling multi-arch (it covers both LE and BE > >> for 64 and 32 bits). > >> > >> Co-authored-by: Richard Henderson > >> --- > >> string/strchrnul.c | 156 +++--------------- > >> .../power4/multiarch/strchrnul-ppc32.c | 4 - > >> sysdeps/s390/strchrnul-c.c | 2 - > >> 3 files changed, 24 insertions(+), 138 deletions(-) > >> > >> diff --git a/string/strchrnul.c b/string/strchrnul.c > >> index 0cc1fc6bb0..67defa3dab 100644 > >> --- a/string/strchrnul.c > >> +++ b/string/strchrnul.c > >> @@ -1,10 +1,5 @@ > >> /* Copyright (C) 1991-2022 Free Software Foundation, Inc. > >> This file is part of the GNU C Library. > >> - Based on strlen implementation by Torbjorn Granlund (tege@sics.se), > >> - with help from Dan Sahlin (dan@sics.se) and > >> - bug fix and commentary by Jim Blandy (jimb@ai.mit.edu); > >> - adaptation to strchr suggested by Dick Karpinski (dick@cca.ucsf.edu), > >> - and implemented by Roland McGrath (roland@ai.mit.edu). > >> > >> The GNU C Library is free software; you can redistribute it and/or > >> modify it under the terms of the GNU Lesser General Public > >> @@ -21,146 +16,43 @@ > >> . */ > >> > >> #include > >> -#include > >> #include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> > >> #undef __strchrnul > >> #undef strchrnul > >> > >> -#ifndef STRCHRNUL > >> -# define STRCHRNUL __strchrnul > >> +#ifdef STRCHRNUL > >> +# define __strchrnul STRCHRNUL > >> #endif > >> > >> /* Find the first occurrence of C in S or the final NUL byte. */ > >> char * > >> -STRCHRNUL (const char *s, int c_in) > >> +__strchrnul (const char *str, int c_in) > >> { > >> - const unsigned char *char_ptr; > >> - const unsigned long int *longword_ptr; > >> - unsigned long int longword, magic_bits, charmask; > >> - unsigned char c; > >> - > >> - c = (unsigned char) c_in; > >> - > >> - /* Handle the first few characters by reading one character at a time. > >> - Do this until CHAR_PTR is aligned on a longword boundary. */ > >> - for (char_ptr = (const unsigned char *) s; > >> - ((unsigned long int) char_ptr & (sizeof (longword) - 1)) != 0; > >> - ++char_ptr) > >> - if (*char_ptr == c || *char_ptr == '\0') > >> - return (void *) char_ptr; > >> - > >> - /* All these elucidatory comments refer to 4-byte longwords, > >> - but the theory applies equally well to 8-byte longwords. */ > >> - > >> - longword_ptr = (unsigned long int *) char_ptr; > >> - > >> - /* Bits 31, 24, 16, and 8 of this number are zero. Call these bits > >> - the "holes." Note that there is a hole just to the left of > >> - each byte, with an extra at the end: > >> - > >> - bits: 01111110 11111110 11111110 11111111 > >> - bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD > >> - > >> - The 1-bits make sure that carries propagate to the next 0-bit. > >> - The 0-bits provide holes for carries to fall into. */ > >> - magic_bits = -1; > >> - magic_bits = magic_bits / 0xff * 0xfe << 1 >> 1 | 1; > >> - > >> - /* Set up a longword, each of whose bytes is C. */ > >> - charmask = c | (c << 8); > >> - charmask |= charmask << 16; > >> - if (sizeof (longword) > 4) > >> - /* Do the shift in two steps to avoid a warning if long has 32 bits. */ > >> - charmask |= (charmask << 16) << 16; > >> - if (sizeof (longword) > 8) > >> - abort (); > >> - > >> - /* Instead of the traditional loop which tests each character, > >> - we will test a longword at a time. The tricky part is testing > >> - if *any of the four* bytes in the longword in question are zero. */ > >> - for (;;) > >> - { > >> - /* We tentatively exit the loop if adding MAGIC_BITS to > >> - LONGWORD fails to change any of the hole bits of LONGWORD. > >> - > >> - 1) Is this safe? Will it catch all the zero bytes? > >> - Suppose there is a byte with all zeros. Any carry bits > >> - propagating from its left will fall into the hole at its > >> - least significant bit and stop. Since there will be no > >> - carry from its most significant bit, the LSB of the > >> - byte to the left will be unchanged, and the zero will be > >> - detected. > >> + /* Set up a word, each of whose bytes is C. */ > >> + op_t repeated_c = repeat_bytes (c_in); > >> > >> - 2) Is this worthwhile? Will it ignore everything except > >> - zero bytes? Suppose every byte of LONGWORD has a bit set > >> - somewhere. There will be a carry into bit 8. If bit 8 > >> - is set, this will carry into bit 16. If bit 8 is clear, > >> - one of bits 9-15 must be set, so there will be a carry > >> - into bit 16. Similarly, there will be a carry into bit > >> - 24. If one of bits 24-30 is set, there will be a carry > >> - into bit 31, so all of the hole bits will be changed. > >> + /* Align the input address to op_t. */ > >> + uintptr_t s_int = (uintptr_t) str; > >> + const op_t *word_ptr = word_containing (str); > >> > >> - The one misfire occurs when bits 24-30 are clear and bit > >> - 31 is set; in this case, the hole at bit 31 is not > >> - changed. If we had access to the processor carry flag, > >> - we could close this loophole by putting the fourth hole > >> - at bit 32! > >> + /* Read the first aligned word, but force bytes before the string to > >> + match neither zero nor goal (we make sure the high bit of each byte > >> + is 1, and the low 7 bits are all the opposite of the goal byte). */ > >> + op_t bmask = create_mask (s_int); > >> + op_t word = (*word_ptr | bmask) ^ (repeated_c & highbit_mask (bmask)); > > > > Think much clearer (and probably better codegen) is: > > find_zero_eq_low/all(word, repeated) >> (s_int * CHAR_BIT) > > It does not seem to work, at least not replacing the two lines with: > > op_t word = find_zero_eq_all/low (*word_ptr, repeated_c) >> (s_int * CHAR_BIT); > > The loader itself can not loader anything (which means strchr is failing > somewhere). The following works for me (only checking test-strchrnul, so maybe its missing a case), also as I have it here its only little endian. (Would need an ifdef here or API for shifting out out-of-bounds bits for cross platform). ``` op_t word = *word_ptr; op_t mask = find_zero_eq_low(word, repeated_c) >> (CHAR_BIT * (s_int % sizeof(uintptr_t))); if(mask) { return (char *) str + index_first_(mask); } while (! has_zero_eq (word, repeated_c)) word = *++word_ptr; op_t found = index_first_zero_eq (word, repeated_c); return (char *) (word_ptr) + found; ```