From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 980853858416 for ; Thu, 21 Oct 2021 20:06:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 980853858416 Received: by mail-qt1-x82b.google.com with SMTP id g17so1601791qtk.8 for ; Thu, 21 Oct 2021 13:06:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=RbaY/13f4YrlT8ehakNhWeEfxAZhVnJJxU7szUcN2aE=; b=TIbuYgyrHuMoKO0w4w7RUtnGzEgsGRl5B2oQN6LrGwAt5wthNXWfUAiUOZlVFHSqve JBWTA8/+jImCcNUSrE+dWxEzFDD4ftfq1Jr843OJsQncKZCKu9QJkwq2mYBVeCU007gN +b6x/10+13OPEgpwZNY8X9MPZChWJgxOHfF10iC0/m7EOClaTffbmJz1EzOUHm5a+DrF 4KTDWdGMQLhRMiC8mar3abNQJF7t9W4dbUQX2Kk4wOX7Cs/2D7t9YlIabs1ITjioIgP9 1iHqmbBwGCcnDvRM7NNOkwDbAw+SYpOBka+y37u+/N8gUPOb0qPp4HkRO17nbdRmZ4DT 4nQA== X-Gm-Message-State: AOAM532Tz0IdNK1qVUHdVyL20JrQKkZXX3KHcprVIiLscyRLZmlfsVnu Gso0qDpK5bA9e3Gx5kHGSQcwWmFRuoVubg== X-Google-Smtp-Source: ABdhPJxmxsD/08h1UhUYSFjfrkJjcDSdPPMK6AhDjw5dxZqeGjvXZaIx0ZD9rs31VPqtYyfaL3dwAA== X-Received: by 2002:a05:622a:1993:: with SMTP id u19mr8434120qtc.119.1634846797175; Thu, 21 Oct 2021 13:06:37 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:2654:4963:d466:e6c9:ddbb? ([2804:431:c7ca:2654:4963:d466:e6c9:ddbb]) by smtp.gmail.com with ESMTPSA id u10sm3081569qtx.68.2021.10.21.13.06.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Oct 2021 13:06:36 -0700 (PDT) Message-ID: <759a52ae-1cca-6b1b-919f-fea7744594fc@linaro.org> Date: Thu, 21 Oct 2021 17:06:34 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCH v7] String: Add support for __memcmpeq() ABI on all targets Content-Language: en-US To: Noah Goldstein Cc: GNU C Library References: <20210927203827.2852935-1-goldstein.w.n@gmail.com> <20210929151743.3351092-1-goldstein.w.n@gmail.com> <8ee11473-cdfd-3dbe-47a1-dffddc996b34@linaro.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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:06:38 -0000 On 21/10/2021 17:01, Noah Goldstein 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. But you are exporting the double underscore symbol on an installed header, so it would be visible to users as well. I wonder if it would be better to only export 'memcmpeq' as a GNU extension on string.h and '__memcmpeq' as a global symbol without a prototype (so only compiler generated objects will have bindings to '__memcmpeq'). > >> >> 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? > Right, in this patch or in subsequent patch is fine.