From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 83C311F8C6 for ; Wed, 15 Sep 2021 18:30:56 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8C5AD3857402 for ; Wed, 15 Sep 2021 18:30:55 +0000 (GMT) Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 840563858C39 for ; Wed, 15 Sep 2021 18:30:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 840563858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: ftgxSZNRT/mGiU4/J7HPUKPL6z4xli26NG5gPIk9IfZK7Ank/C58pkkDLBSFWR2M76sc61QcRT 9Bwbh3HNSt8nhVGEMG0TPENpU1f0ZrfUaKBuHqxn8Umti8LZUrU3DiBuTzLGepRvtiZ5nTWIkr 0FS7IyJnzjTjprLAmFlhUn8U58dW9JzVDkOrZ+NPam2u3ljmQt5Jbq8w1a7kxoL1n7ZysnvRrR Bz1KP7qTk7vAH8U00y6nrjxr5t3aKTnofTN30lYxAsu8eNKv5uLwcxpjPPFAeherLJMBxijHTD sLAjTpLrWTHsD+PKi0hpSNmR X-IronPort-AV: E=Sophos;i="5.85,296,1624348800"; d="scan'208";a="66096346" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 15 Sep 2021 10:30:42 -0800 IronPort-SDR: ONcKAvEKi/MOUZUBHpuKIseAlAcCpJrFvJb4wMpQRMvcTIm84s3J2jhkmqo0izlJteeQWdnFBr 7YlYlhMtd9j8eOTJjECjWg8C8Qclr60ns1sWt/fxwgcPYfEkRJzpTn3hTiOjDuqDR6oqcrSQ4p emQ3CUeHP8ijJ4E7s1WocGL47TJPc1Zj3bHm7HzgTduWqud9rOu+9VtKe5/4+Jjlk37OAG405U MeSLCQtCo7Ihw+O0bfO3SM0Orm43nm04usF1H3+R07XkfR2ohCJzkHIl8yDLU3VzOQPgLX2dVP Y0I= Date: Wed, 15 Sep 2021 18:30:37 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Noah Goldstein Subject: Re: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse 4_1, avx2, and evex In-Reply-To: Message-ID: References: <20210913230506.546749-1-goldstein.w.n@gmail.com> <02afac02-47a5-43a5-8437-79fdbbea62aa@www.fastmail.com> <87mtoerl85.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Zack Weinberg , Zack Weinberg via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Wed, 15 Sep 2021, Noah Goldstein via Libc-alpha wrote: > > > I do rather like the idea of a __gnu_memeq() that compilers could > > > optimize memcmp calls to, when they can prove that the result is used > > > only for its truth value. > > > > Yes, we should use a name in the implementation namespace because even > > if we pick an obvious like memequal, it will probably come back under a > > different name from the C committee. > > > > +1 > > What would be the steps for getting that into GLIBC? Define what the exact interface you want is (the exact function type and (reserved) name and semantics of the return value and arguments; explicitly including details such as whether the full n bytes of each argument are required to be mapped into memory even if they compare unequal before n bytes). Discuss it on the libc-coord mailing list (probably include compiler mailing lists as well) to get agreement on semantics that are good for both libc implementations and for compilers to generate; it's best if this interface is acceptable to multiple libc implementations and suitable for multiple compilers to generate calls to (when available in libc). Implement in glibc, across all glibc ports and including all the ABI test baseline updates. If the semantics are such that an alias to memcmp is a valid implementation, that probably means adding such an alias to every memcmp implementation in glibc (and verifying with build-many-glibcs.py that they all build and pass the ABI tests), as well as allowing for architectures to add their own separate implementation of the new function if they wish. There should also be execution tests that the new function works correctly at runtime (with different alignment, arguments just before unmapped pages, etc., as with other string function tests). If the new function is purely an ABI, not an API, it doesn't need user manual documentation, however (although there will at least need to be a comment giving the detailed semantics that were agreed on libc-coord). -- Joseph S. Myers joseph@codesourcery.com