From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 7167D3858C39 for ; Wed, 15 Sep 2021 18:06:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7167D3858C39 Received: by mail-pj1-x1029.google.com with SMTP id t20so2686692pju.5 for ; Wed, 15 Sep 2021 11:06:42 -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=aqeHUwn1WwIfXxOQwFxYI6CRQtmbOzkRTv4Pb8JWdm8=; b=7nbCH0aDFmz6GMtAZ76WILTz52QTWhJzTS5haw/RvkPNsAF9hL+DW8JOjWqnllKXzw jFUE9OWfCT9C6I9IsiYSCTiHEACF/lzoaVkBXghMS4OTh+RuQDf9dIvwriruBfghv7Eh 5wkoPnNa4qoRJvlyuQ6jJCj/52srwdsK1mnhTuY+28JWDecVoV/IpZlBUxbvNf113qUr n/LjOPOqfL8XYWAv93qpxNTBm0eXOTMsU1fh6fSl+3kOUAMMQrdRMocWTrkFnMGq3t0P zAdw715K2wv5xIdwTYsusriCZ0WxZqxlGBRg+h0VuuwLXGb/szLqrOmjHnhTGSpkp0FL v3Ig== X-Gm-Message-State: AOAM532rlJNTqfSXtnYC9WhOoe30CJy0Vh8gdkJp3Wix7OZk2X8zB+5F vCoUmvZ/In4H992PC+egZ6cSz1RBNVrpzZGB4+axBsnwZLY= X-Google-Smtp-Source: ABdhPJx8+AmOPLMtP062re5r7FUuC1FTgQ2RKMVPDmW6v0cMtBCag5xrMXjGgRe5PFbigxx7QmlmhKiOK/AofZdysiQ= X-Received: by 2002:a17:90b:180a:: with SMTP id lw10mr9959845pjb.87.1631729201574; Wed, 15 Sep 2021 11:06:41 -0700 (PDT) MIME-Version: 1.0 References: <20210913230506.546749-1-goldstein.w.n@gmail.com> <02afac02-47a5-43a5-8437-79fdbbea62aa@www.fastmail.com> <87mtoerl85.fsf@oldenburg.str.redhat.com> In-Reply-To: <87mtoerl85.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Wed, 15 Sep 2021 13:06:28 -0500 Message-ID: Subject: Re: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse 4_1, avx2, and evex To: Florian Weimer Cc: Zack Weinberg via Libc-alpha , Zack Weinberg X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 15 Sep 2021 18:06:45 -0000 On Wed, Sep 15, 2021 at 9:02 AM Florian Weimer via Libc-alpha < libc-alpha@sourceware.org> wrote: > * Zack Weinberg via Libc-alpha: > > > On Tue, Sep 14, 2021, at 8:00 PM, Joseph Myers wrote: > >> 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. > > > > I want to add that glibc has made bcmp an alias for memcmp for many > > years, which means that Linux- or Hurd-specific programs that are > > still using bcmp may have come to depend on its return value > > indicating ordering rather than just equality. I myself had been > > under the impression that they were *specified* exactly the same, > > until this thread prompted me to double-check the specifications. As > > such I don't think it's safe for *glibc* to accept patches that > > optimize bcmp separately from memcmp. > > That's a very good point. > > > 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? > > Thanks, > Florian > >