From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id E80053858416 for ; Thu, 21 Oct 2021 23:14:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E80053858416 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: qlcEXy/JF5TFtR/PV1GY4McMAcGyI+AIal7mwnkkGoTqZTXDlY1VEJKwTCHTtBmvR+F34bVhTk YDjm6DCVL1Y7Yn1zE40K2jwgSp9tVQA9bwu8AZLWWfJDA+bVO1h01QxwqqK4peNAOP5+V0YWrE SJEzGYyzqiJl/jTSegUGdYtzLEP2LtXdeoro2buZhGmXs3MU9YNTV7uPpC3oxLqjKFaahuFzWR yDXfrip5W3Q2ZNrmrraAcq1JaXOTtvy4IdxOBlZy9A67BoganLJ01dVffLMyscMmtmJKrGZh5+ oZUaGhoKlpayT2e5Q+8cvA6s X-IronPort-AV: E=Sophos;i="5.87,170,1631606400"; d="scan'208";a="67357760" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 21 Oct 2021 15:14:57 -0800 IronPort-SDR: XlhhzXvVw0zSEcSRQWeR1RV8gJbnT0ysGVRpybEdF9RfckQMKwN7GM3vShCFbeescPk4aKbMQH K1rVIa6cHLhfCuyjArIqLZNR977cogOfsFIIw8OmqiIDtG/Ad6f1yi+pGAJpg2Gpqnqf7z0vBx 45C1FPafPEDKVTXTWckzm8Y40YBrDz7mNzB1Gk7YWX3d4z8m8eTnv0aoPDseHrhrbvszNOD9Xz bRbe9KJve1t4cKVJsjsbGCj1lP53+8i/8FruuktgHwMcqf5tUwxwdU1ErOnakvCqs3f04jIqtD jno= Date: Thu, 21 Oct 2021 23:14:51 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "H.J. Lu" CC: GNU C Library Subject: Re: [PATCH v8 2/3] String: Add hidden defs for __memcmpeq() to enable internal usage In-Reply-To: Message-ID: References: <20210927203827.2852935-1-goldstein.w.n@gmail.com> <20211021223850.415607-1-goldstein.w.n@gmail.com> <20211021223850.415607-2-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-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 21 Oct 2021 23:14:59 -0000 On Thu, 21 Oct 2021, H.J. Lu via Libc-alpha wrote: > On Thu, Oct 21, 2021 at 4:08 PM Joseph Myers wrote: > > > > On Thu, 21 Oct 2021, H.J. Lu via Libc-alpha wrote: > > > > > There are many memcmp calls in ld.so. I think most, if not all, of them > > > can be changed to __memcmpeq. Can you make another patch to do > > > that? > > > > Rather than doing that micro-optimization in the glibc sources, I think > > it's better to add the relevant feature to GCC and let glibc get optimized > > when built with a new-enough compiler. > > Why not? We don't know when __memcmpeq will be supported by GCC > used by glibc developers. If we don't even use it in glibc, why bother? The point of this function is entirely for compilers to generate for calls from memcmp, not for humans to write direct calls to. The compiler knows other semantics of memcmp (it might sometimes expand a memcmp with a small fixed size inline, for example). So changing to a direct call to __memcmpeq by hand isn't even always an optimization; it seems better to leave the semantics visible to the compiler. Note that in other cases we've generally moved *towards* relying on built-in functions rather than having our own local inline expansions of those or calls to internal names for those functions (we've done that for calls to various functions in libm, for example). -- Joseph S. Myers joseph@codesourcery.com