From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id CF0153858C5E for ; Fri, 3 Feb 2023 00:24:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF0153858C5E 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-pj1-x1035.google.com with SMTP id n20-20020a17090aab9400b00229ca6a4636so7320253pjq.0 for ; Thu, 02 Feb 2023 16:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MXTDnnOFUNVi/OWsrBgUOPwsgHW25k4By7TZbpCY8ow=; b=nLPEekkdjsRLaEpuf4+emXdjUckT+wXdC71TAncYIiL5YucnW9KQMdbRrdimdTn7eq fMwz7xZytyBtKUHK0uHYvdIRI4A17O6c11CBjBoi2zuHQ9RSzxdWAdNxD1pqDZxSHSRW EFfZV/eUKE5JGKKnRD63i0L1g5KiqDLs/ThYXkhNGb3Dtu6QfKNLG+aUd7FFEF8VmDot ml/9jybR2izIcmCsGqmww8L0Q6SVH8JFSBSV1W8SyKYHIkReZ55+k9mrsY9roJ1AFKl/ 6+GqwC6mYsVVo1halB543m08yph/KQQ+6QRo5tQVkTZi/RYsX1jSrluqQxb/pPmbMbhg UMoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references: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=MXTDnnOFUNVi/OWsrBgUOPwsgHW25k4By7TZbpCY8ow=; b=0MAyiHx2yhbTTWE5nwg9fhvP0aQu0DrAjY68X1Lcg5aQBvpPROiGRy1gfed9ws8QZ/ vi1M13w7sOB05lEEWwmzfqVDz+b/iS2Iao8gaEEIuLv3rtTSfpK1ObcaRk9kKdDTWeeS F+sbDnohSpFIbY99glNE+HUrM9vRvczUZ7DJbAi+5Ap7DHbct7rjCoqKJvOj1tznjany F1WA0r4eEFPMosgeYY85EjjJ06k62hR86uRQpaqDLzPMtUf6oElGmA1RGTYtKbRmkDfj JNShlBY4Ko7dQr6moVb6C2p9uJzdqJRT4WFRNNITGtpYLCfV4ch5S3fmWf0EkT+m+n1P rwUA== X-Gm-Message-State: AO0yUKWfM+AR1x59KOD3eZo+KSDHxOaL/9POqjrIwFSXAgBUAwy8q/a3 slHn+26KM8jQmQI2Be9FmxR1Hcgf38QIyVGM X-Google-Smtp-Source: AK7set+4ZKr1Tl5gpKYNXLrzv1xd+M5O7rleuLeXODrYjDstrk5Ol9N+L9Z3BJl3OkvC67PSXXjm2A== X-Received: by 2002:a17:902:e2d1:b0:194:6679:87fa with SMTP id l17-20020a170902e2d100b00194667987famr6381855plc.32.1675383857856; Thu, 02 Feb 2023 16:24:17 -0800 (PST) Received: from [192.168.50.194] (rrcs-173-197-98-118.west.biz.rr.com. [173.197.98.118]) by smtp.gmail.com with ESMTPSA id bt25-20020a632919000000b004dea53e52desm366856pgb.27.2023.02.02.16.24.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Feb 2023 16:24:17 -0800 (PST) Message-ID: Date: Thu, 2 Feb 2023 14:24:12 -1000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v12 03/31] Add string vectorized find and detection functions Content-Language: en-US To: Adhemerval Zanella , libc-alpha@sourceware.org, Jeff Law , Xi Ruoyao , Noah Goldstein References: <20230202181149.2181553-1-adhemerval.zanella@linaro.org> <20230202181149.2181553-4-adhemerval.zanella@linaro.org> From: Richard Henderson In-Reply-To: <20230202181149.2181553-4-adhemerval.zanella@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 2/2/23 08:11, Adhemerval Zanella wrote: > +/* With similar caveats, identify zero bytes in X1 and bytes that are > + not equal between in X1 and X2. */ > +static __always_inline find_t > +find_zero_ne_low (op_t x1, op_t x2) > +{ > + return (~find_zero_eq_low (x1, x2)) + 1; > +} This is no longer used, and suspected buggy. Duh, I now see why it's buggy -- it's inverting both zero comparison and eq comparison -- we wanted to invert only eq. Let's remove this rather than attempting to fix. I suspect it'll work out very similar to our existing find_zero_ne_all(). > +/* Similarly, but perform the search for byte equality between X1 and X2. */ > +static __always_inline unsigned int > +index_first_zero (op_t x1, op_t x2) > +{ > + if (__BYTE_ORDER == __LITTLE_ENDIAN) > + x1 = find_zero_low (x1, x2); > + else > + x1 = find_zero_all (x1, x2); > + return index_first (x1); > +} ... > +/* Similarly, but search for the last zero within X. */ > +static __always_inline unsigned int > +index_last_zero (op_t x) > +{ > + return index_last (find_zero_all (x)); > +} Why did this lose the __BYTE_ORDER test? It should be the inverse of index_first_zero. > +static __always_inline unsigned int > +index_last_eq (op_t x1, op_t x2) > +{ > + return index_last_zero (x1 ^ x2); > +} Similarly. r~