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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 9E1391F8C6 for ; Wed, 15 Sep 2021 00:01:14 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4A12D3857825 for ; Wed, 15 Sep 2021 00:01:13 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id A97FB3858402 for ; Wed, 15 Sep 2021 00:01:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A97FB3858402 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: OQZ8Mr8BCDESwFFCHB2QWrm4GVBE7wG2OGqKzOZaDnrmkKJVkb9SvJDjGG87CUQbmqqLtHejXy dhXkjS2SFX4Xwq0e7B00bu9vkkyi5uGMoqgHmqFTjgdepT9mUiNXwa8a64ERWAPyAfU+A6gwA5 nrzQbziW5G7Nc3wIjVJGf9gRitdu2mABxrQ5SmHN1H4JkGE42MvoyPlEZEnIJNEnLSmyG7pP7t J690lwGo9Si9WOkBpdn5fcT04w8oWulwyYeyMJaSs5LangrqarEj3lOGuVsAWz5Q3OJAXCcCMx JLEy9RvLmntrkmfCYxZwpfpO X-IronPort-AV: E=Sophos;i="5.85,292,1624348800"; d="scan'208";a="65868807" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 14 Sep 2021 16:01:00 -0800 IronPort-SDR: Ujr+NnXMX7E6GQGW4MMszO+Q+r/YHMoGJkOEAJLVTtOAA+oN2LFNsnL57WIVQGSpbUGQhFdJsK 4Kux8x67fx/kSzM7mwAfAIHHJBxkLdgr4oLEKjXSLIsPj5pKgVrtAVjqS4YdA9Z2Kd85wdmvQU VECNVKJKBfmlTPrwXxr0RZ9WFBuo1Swgp6/PjMSgSn0MpSnv/1HlLdfMb26pfbiNxga8TF4pZf jWRAj1SVRdTwETbfBipby6rcFl1LN6P6Sj+K3ylITF4k/pS3NoOjpeeKoxS5IrnDrfHOlOCej6 qYc= Date: Wed, 15 Sep 2021 00:00:55 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Noah Goldstein Subject: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex In-Reply-To: <20210913230506.546749-1-goldstein.w.n@gmail.com> Message-ID: References: <20210913230506.546749-1-goldstein.w.n@gmail.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-08.mgc.mentorg.com (139.181.222.8) 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: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" bcmp is an obsolescent function that no modern programs should be using, and it's not in the implementation namespace either so compilers shouldn't translate memcmp calls to bcmp. If you want to define memcmp ABI variants optimized for particular usages, I suggest the following: 1. Add reserved-namespace names for such variants to the x86_64 psABI document (working with the ABI mailing list). The 32-bit Arm RTABI provides a precedent for defining such function variants in a psABI (it includes various __aeabi_mem*, though no memcmp variants). 2. Add those names to glibc, as well as teaching compilers to generate calls to them (with appropriate conditionals for whether the functions are known to be available in the target libc; in GCC, that would be based on GCC_GLIBC_VERSION_GTE_IFELSE configure tests for targets using glibc). As a variant, you could define such names as architecture-independent GNU extensions rather than in a psABI, especially if there's nothing architecture-specific about the variants you think are useful (e.g. no use for having changes to calling conventions / call-clobbered registers for the variants). But what should not be done in any case is tying an optimization to an obsolescent non-reserved name - any such optimized variants should use only implementation-namespace names. -- Joseph S. Myers joseph@codesourcery.com