From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by sourceware.org (Postfix) with ESMTPS id AFDF73858D20 for ; Mon, 9 Jan 2023 18:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AFDF73858D20 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-oa1-x2f.google.com with SMTP id 586e51a60fabf-14ffd3c5b15so9559284fac.3 for ; Mon, 09 Jan 2023 10:19:52 -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=OlYyYYomOqWWrMo24ci+Af7PHxi6CHzQREyPj0UFVc0=; b=dBBLnAv1Cyq9+arpmapyrDmC7QclkA/mAMWLsObPgR5wrX11V3D4bwOU1WLG1Z5f8s Ghizd2iRqzNbOtZQKd7zbVIYQfw+z+ien8UNlKAhFa5YwqlS2AMEns8URTif/ceSEve/ oKMiNpmidpfDoTfXqzrSUjLvJRNH5m8l79AScu7jsLARJYGDSZL4vdH/gTLjiDoDDGT6 tlTbh/un0V7a+UnHgrOv/prokeepxBD1t4ZIlRr/AbzxqNZYroYEtppaKrHEAzf9XptS wpDFGV57bphoNmlcM+AHRL4ZQOAHQpCoYwTLsZzjuBSnPYyKGG8Sn2HpyiHdFpTWAIoP oZUA== 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=OlYyYYomOqWWrMo24ci+Af7PHxi6CHzQREyPj0UFVc0=; b=WZ48XeZS2bX21rfidfSnsNFZl6u5ZwUiysTPDgb76AsWGjnNon1ljRV29bpfmmfS9i aXQr3SvQsq/00GLIFVS6dCytho25sZ/mF7xjsECXV6ZzNKpTXcaYPYYXcdqaNAnymlQY 034N704FXcJVBRjXEw6fwsDrYgOw9THjf+z++jptkc4cweHymGz+iGrOxPPMLpCSIi3F SEiR3rMYE5sr6NKWqNNUFOQKCcrvyx/DgT7Qr2Ap7rNFN1MN4Mnz/PQ7QLRdHajRD5rb Ync8U0PYafB7fHtB7v4hmpGInapYcODyTaz0cJ6WgZ8BZVY7Qf3Ej1f6qSEELE2eKo9V 52Bg== X-Gm-Message-State: AFqh2kpJBIYL9mPnvRwkd9sy69HejEU34b5J9vzWwFO48FR2+K+wzyc8 vUwsYyCcClCI7ghQz0vqK5xZPw== X-Google-Smtp-Source: AMrXdXva2mg/kAGDAO2wNWLcsXiF+/rjXb3TlpG4IRXYPWtJvW9SP72bcA/5vqpHc6n/lQdNdBMRbA== X-Received: by 2002:a05:6870:fd83:b0:150:cdf1:a7b6 with SMTP id ma3-20020a056870fd8300b00150cdf1a7b6mr11053572oab.5.1673288391921; Mon, 09 Jan 2023 10:19:51 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:a93a:9d68:9321:503b:c278? ([2804:1b3:a7c0:a93a:9d68:9321:503b:c278]) by smtp.gmail.com with ESMTPSA id 42-20020a9d012d000000b006619295af60sm447329otu.70.2023.01.09.10.19.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Jan 2023 10:19:50 -0800 (PST) Message-ID: Date: Mon, 9 Jan 2023 15:19:48 -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 03/17] Add string-maskoff.h generic header Content-Language: en-US To: Alejandro Colomar , Noah Goldstein Cc: libc-alpha@sourceware.org References: <20220919195920.956393-1-adhemerval.zanella@linaro.org> <20220919195920.956393-4-adhemerval.zanella@linaro.org> <8c026b5b-9f65-dda4-83a8-daf2ec9b3355@gmail.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <8c026b5b-9f65-dda4-83a8-daf2ec9b3355@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,BODY_8BITS,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:26, Alejandro Colomar wrote: > > > On 1/5/23 23:49, Noah Goldstein via Libc-alpha wrote: >> On Mon, Sep 19, 2022 at 12:59 PM Adhemerval Zanella via Libc-alpha >> wrote: >>> >>> Macros to operate on unaligned access for string operations: >>> >>>    - create_mask: create a mask based on pointer alignment to sets up >>>      non-zero bytes before the beginning of the word so a following >>>      operation (such as find zero) might ignore these bytes. >>> >>>    - highbit_mask: create a mask with high bit of each byte being 1, >>>      and the low 7 bits being all the opposite of the input. >>> >>> These macros are meant to be used on optimized vectorized string >>> implementations. >>> --- >>>   sysdeps/generic/string-maskoff.h | 73 ++++++++++++++++++++++++++++++++ >>>   1 file changed, 73 insertions(+) >>>   create mode 100644 sysdeps/generic/string-maskoff.h >>> >>> diff --git a/sysdeps/generic/string-maskoff.h b/sysdeps/generic/string-maskoff.h >>> new file mode 100644 >>> index 0000000000..831647bda6 >>> --- /dev/null >>> +++ b/sysdeps/generic/string-maskoff.h >>> @@ -0,0 +1,73 @@ >>> +/* Mask off bits.  Generic C version. >>> +   Copyright (C) 2022 Free Software Foundation, Inc. >>> +   This file is part of the GNU C Library. >>> + >>> +   The GNU C Library is free software; you can redistribute it and/or >>> +   modify it under the terms of the GNU Lesser General Public >>> +   License as published by the Free Software Foundation; either >>> +   version 2.1 of the License, or (at your option) any later version. >>> + >>> +   The GNU C Library is distributed in the hope that it will be useful, >>> +   but WITHOUT ANY WARRANTY; without even the implied warranty of >>> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU >>> +   Lesser General Public License for more details. >>> + >>> +   You should have received a copy of the GNU Lesser General Public >>> +   License along with the GNU C Library; if not, see >>> +   .  */ >>> + >>> +#ifndef _STRING_MASKOFF_H >>> +#define _STRING_MASKOFF_H 1 >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* Provide a mask based on the pointer alignment that sets up non-zero >>> +   bytes before the beginning of the word.  It is used to mask off >>> +   undesirable bits from an aligned read from an unaligned pointer. >>> +   For instance, on a 64 bits machine with a pointer alignment of >>> +   3 the function returns 0x0000000000ffffff for LE and 0xffffff0000000000 >>> +   (meaning to mask off the initial 3 bytes).  */ >>> +static inline op_t >>> +create_mask (uintptr_t i) >>> +{ >>> +  i = i % sizeof (op_t); >>> +  if (__BYTE_ORDER == __LITTLE_ENDIAN) >>> +    return ~(((op_t)-1) << (i * CHAR_BIT)); >>> +  else >>> +    return ~(((op_t)-1) >> (i * CHAR_BIT)); >>> +} >>> + >>> +/* Setup an word with each byte being c_in.  For instance, on a 64 bits >>> +   machine with input as 0xce the functions returns 0xcececececececece.  */ >>> +static inline op_t > > Hi Adhemerval and Noah, > > I don't know what is the minimum C version for compiling glibc, but if you can ignore C89, I would propose something: > > 'static inline' should be restricted to .c files, since if the compiler decides to not inline and you have it in a header, you end up with multiple static definitions for the same code. > > In headers, I use C99 inline, which doesn't emit any object code when the compiler decides to not inline.  Then in a .c file, you add a prototype using 'extern inline', and the compiler will emit code there, exactly once. > > Even if you have to support C89, I'd use [[gnu::always_inline]] together with 'static inline', to make sure that the compiler doesn't do nefarious stuff. Although we build glibc with -std=gnu11 we also uses -fgnu89-inline, but regardless of the inline mode 'multiple definitions' it is usually not an issue. We do use __always_inline in performant code, so it should be ok to use it here as well (although I would expect that compiler will always inline these short functions).