From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by sourceware.org (Postfix) with ESMTPS id 2C81B3858CDA for ; Mon, 9 Jan 2023 20:35:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C81B3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oo1-xc32.google.com with SMTP id o5-20020a4a2c05000000b004ac6ea6c75dso2721066ooo.8 for ; Mon, 09 Jan 2023 12:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=XjtxcHsvVpUf/wtFR82q4mtQtiPxo071X5c2sMRVh1U=; b=U27a5WMLjYBSO4iAnRK16X8z0wDnqZD7bO9OqW0pBFqOvhbeMbLYr+OB/frSnm41TU drhp4g53WdcLL29Lme8bNrBxmczoat/D/Z1yQRNj1U7KXAUb285sVKO5EOHt7yViYC3W /yEfqhF+Ty+D8LqosRFvS2h77DAE2O2LRNLp2mEf8opPp0vizuHCedjxyeStW3YhCcua R+Wk6OnJa9BavYwPrUdPaYtAcZcaV0FfoUT7v8VFzlH2NCwAqMYXsPOp48+x5O9yFILL fRtbqgXtG40Nfdg5gVL9rvf+GNbTUZyhuzqOlskuweHVgSLsF0X/M9UxibYiHSiXNfSv cKqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XjtxcHsvVpUf/wtFR82q4mtQtiPxo071X5c2sMRVh1U=; b=Q+cYB0vVRc0EEuyI9UF+RaF3F4PCAnwvWmWsYWLreLjqJJZ1vVgMBoAX/CKwMI43yG fdOXjUnPdVLSaZ9FSnUNTzNgB97N+WAT/eo5Vjxpnqeu6SRgt/kd44FUQHu0d38b/FGD Yktq+Uv7fxjEapSI/2T+eP/mUHBzYOgHLzQygH6s0oo/K5eHGYu1FL9P2FZkuchLuDZz 1bOauvssD/Xfn8LGePME1E/4gObToDq6CCQIVGx8Vtfvh1i13mCSrbqa+edLnxwXhnru jHUqNkUI3auj+ycQ0t2lVyUYd3WEutxjtzrN3iAhlqsjfaiJA5cq18RvkzPKmsrf3HJq PrPw== X-Gm-Message-State: AFqh2kr96KAFzmszgUWiS8H/ktZ9E/g62sWGG3fO44aydWb9tAu8mubY SoejwveMjzq2x10aMmy+1P4lsLuxpw7h9+3bpf8= X-Google-Smtp-Source: AMrXdXsUH2w0zcMUiP92++5CbySG75DcB9tKjK2WymCF54uw43EO5QOj05N0EBv/8TbycC2Dhq6etg== X-Received: by 2002:a4a:e706:0:b0:4e6:f87c:bdf8 with SMTP id y6-20020a4ae706000000b004e6f87cbdf8mr15110939oou.0.1673296519920; Mon, 09 Jan 2023 12:35:19 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a93a:8d00:c4d9:6d86:9f2b? ([2804:1b3:a7c0:a93a:8d00:c4d9:6d86:9f2b]) by smtp.gmail.com with ESMTPSA id k5-20020a056820016500b004a0ad937ccdsm4714118ood.1.2023.01.09.12.35.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jan 2023 12:35:19 -0800 (PST) Message-ID: Date: Mon, 9 Jan 2023 17:35:16 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v5 08/17] string: Improve generic strchrnul Content-Language: en-US To: Noah Goldstein Cc: libc-alpha@sourceware.org, Richard Henderson References: <20220919195920.956393-1-adhemerval.zanella@linaro.org> <20220919195920.956393-9-adhemerval.zanella@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,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 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).