From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 4F44E3858416 for ; Thu, 21 Oct 2021 20:11:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F44E3858416 Received: by mail-pf1-x431.google.com with SMTP id t184so1693806pfd.0 for ; Thu, 21 Oct 2021 13:11:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hCoe8MPQIYiIbrUUPBa2BtgKYCPTiROqMIMZrAgzXno=; b=wJ6pC2ZKge3XenapZutMZ6eu1VOZ6sR5Gc+x5qm01RLP3jor8pzFxlLoTN9XWjt4C5 FJogP/5SlLj9BMmIB1MlzZxTPlyMkDD7KrvLy0L0nIUbEs9U6hLtrQleNfXck4cd4qg2 LBP8gvYnPVTgLHV2v0P6pFcloQ+IEbdgaza38PhK5vIlxTTJSZPGpGrzmPeEXCMT88Aq 70zngvlSvsmYjD3eIB9EENNH39QiBLOMq/pSuNHebcc0K0TGK3byg8b0gV/Luu+jUY5D WGnJBkAdkRBdKL4IESY9+VopiIngSAXVw2DkVmfKaztfr4IMp5gtuRXbNpWJvT+99g1y spFw== X-Gm-Message-State: AOAM533y5gNQs3TDOABFP60VVHw/8h0PE63A4+j98i4D4wYK5qSjJ+ng lJL9eIgXNW7LGH+83mCe8CA7II51rtGKgqoQtNpWwwsK X-Google-Smtp-Source: ABdhPJxdbaXWWgVp1t9NqHNx7o8xPvdnscwle7nQ0ZLg3X290nWmebovqRsngsFu+CvSETcQBK+woHGtntBW0JkzgVk= X-Received: by 2002:a63:7d04:: with SMTP id y4mr6133156pgc.131.1634847105481; Thu, 21 Oct 2021 13:11:45 -0700 (PDT) MIME-Version: 1.0 References: <20210927203827.2852935-1-goldstein.w.n@gmail.com> <20210929151743.3351092-1-goldstein.w.n@gmail.com> <8ee11473-cdfd-3dbe-47a1-dffddc996b34@linaro.org> In-Reply-To: From: Noah Goldstein Date: Thu, 21 Oct 2021 15:11:34 -0500 Message-ID: Subject: Re: [PATCH v7] String: Add support for __memcmpeq() ABI on all targets To: "H.J. Lu" Cc: Adhemerval Zanella , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 20:11:51 -0000 On Thu, Oct 21, 2021 at 3:07 PM H.J. Lu wrote: > > On Thu, Oct 21, 2021 at 1:02 PM Noah Goldstein via Libc-alpha > wrote: > > > > On Thu, Oct 21, 2021 at 2:33 PM Adhemerval Zanella > > wrote: > > > > > > > > > > > > On 29/09/2021 12:17, Noah Goldstein via Libc-alpha wrote: > > > > No bug. > > > > > > > > This commit adds support for __memcmpeq() as a new ABI for all > > > > targets. In this commit __memcmpeq() is implemented only as an alias > > > > to the corresponding targets memcmp() implementation. __memcmpeq() is > > > > added as a new symbol starting with GLIBC_2.35 and defined in string.h > > > > with comments explaining its behavior. Basic tests that it is callable > > > > and works where added in string/tester.c > > > > > > > > As discussed in the proposal "Add new ABI '__memcmpeq()' to libc" > > > > __memcmpeq() is essentially a reserved namespace for bcmp(). The means > > > > is shares the same specifications as memcmp() except the return value > > > > for non-equal byte sequences is any non-zero value. This is less > > > > strict than memcmp()'s return value specification and can be better > > > > optimized when a boolean return is all that is needed. > > > > > > > > __memcmpeq() is meant to only be called by compilers if they can prove > > > > that the return value of a memcmp() call is only used for its boolean > > > > value. > > > > > > > > > > Should we export memcmpeq() as a GNU extension as well? > > > > > > > All tests in string/tester.c passed. As well build succeeds on > > > > x86_64-linux-gnu target. > > > > > > This patch requires a NEWS entry for the new symbol and most likely > > > a manual entry to describe its semantic. > > > > My understanding is that since we are only exporting this symbol for > > compiler use (to optimize boolean use of 'memcmp()') we weren't > > planning to add a manual entry. > > > > > > > > I also think we should model a new testing based on test-memcmp.c > > > to check for multiple alignments and random inputs. > > > > In this patch __memcmpeq is always just memcmp which is tested. > > > > In my followup patch (once this one gets through) to add separate > > implementations for x86_64 I add tests. Would it be better to include > > those tests in this patchset? > > I think we should add it now since someone can add IFUNC for > a non x86-64 target before x86-64 one is landed. Got it. > > With __memcmpeq, bcmp should be an alias of __memcmpeq, > not memcmp. I think we had some concerns that since 'bcmp' had aliased 'memcmp' for so long users may have started relying on the -/+/= behavior. > > -- > H.J.