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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 4B59B1F8C8 for ; Mon, 27 Sep 2021 01:36:24 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C39B13858426 for ; Mon, 27 Sep 2021 01:36:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C39B13858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1632706582; bh=iOqkssE2g/8c5KK2o2kHEkeSo91uqkX8KocMt6NTfkQ=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ALqx5Hy87v2r+sBfcDKxynZn4FCv1pbVVeBBYpIoIGFrjhPgElx0nwv6nfls+ohp3 sAy/CBEH0qbY9zCAGg0BjhnXf1IiXcEKGrowdimPoxAN05HKnpcnN+tWDYdKsHO3EI c/FxaOouVA6y9HYFtI+sLON31L0BhMbo5gerDYv4= Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 381093858C60 for ; Mon, 27 Sep 2021 01:36:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 381093858C60 Received: by mail-pg1-x52d.google.com with SMTP id y186so4890120pgd.0 for ; Sun, 26 Sep 2021 18:36:03 -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=v3UWzcK/n8cb2C3hgcwcglDYUnYNTs59iwsbLkWQ5LU=; b=h4qMARTkCs+hjMLYC4aWFmBYq7LDm/2g20TBgCAzQApsR8f5Oh2PBPuOrxId3WY/Bl kmsyDQzRDrlpim9uOxxWatUB8SV3vlk5v64PkipkcNkHaYEToRXp6TkbkxHrLKMklFSI p/NDRA3y6IOzmIdIBM2xNW0ltjyyuzLCdZNV1lR1+Q85KGrg39ZDxazaHtGxK6COkzrA RosVY5/UFfGyFFlkSTi63VL9IQoNRq7ssYsHc9iP1Icer+iVfw/nARB21V5DzFhV/xPq 1zlU6dtTIRZc9S5sEL0pDGSY7mwgLcJt+jvNXZ/ZusEXd4m80z9p1xQwb0VtnNKuSxDW Qv2w== X-Gm-Message-State: AOAM533Vgp/72m0SLje9CK/KigF0hl+L0hnF2r3x7Y+/g80wn4j7free xG7/MIZNSRZWceY/Nyc2WsLUNIAIg7UVe5tuGqU= X-Google-Smtp-Source: ABdhPJw4k0l/sd3RwTIe57IxjEOXTboozUO+HiWZM18F4iP/4AfEMeOlb5OyfiRqLvKBmSSkTLHJBfd4vk9wmfi1m10= X-Received: by 2002:a62:8c50:0:b0:44b:31ab:b677 with SMTP id m77-20020a628c50000000b0044b31abb677mr21401494pfd.11.1632706562248; Sun, 26 Sep 2021 18:36:02 -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: Date: Sun, 26 Sep 2021 20:35:51 -0500 Message-ID: Subject: Re: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse 4_1, avx2, and evex To: Joseph Myers 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: , From: Noah Goldstein via Libc-alpha Reply-To: Noah Goldstein Cc: Florian Weimer , Zack Weinberg , Zack Weinberg via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Wed, Sep 15, 2021 at 1:30 PM Joseph Myers wrote: > On Wed, 15 Sep 2021, Noah Goldstein via Libc-alpha wrote: > > > > > 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? > > Define what the exact interface you want is (the exact function type and > (reserved) name and semantics of the return value and arguments; > explicitly including details such as whether the full n bytes of each > argument are required to be mapped into memory even if they compare > unequal before n bytes). > > Discuss it on the libc-coord mailing list (probably include compiler > mailing lists as well) to get agreement on semantics that are good for > both libc implementations and for compilers to generate; it's best if this > interface is acceptable to multiple libc implementations and suitable for > multiple compilers to generate calls to (when available in libc). > > Implement in glibc, across all glibc ports and including all the ABI test > baseline updates. If the semantics are such that an alias to memcmp is a > valid implementation, that probably means adding such an alias to every > memcmp implementation in glibc (and verifying with build-many-glibcs.py > that they all build and pass the ABI tests), as well as allowing for > architectures to add their own separate implementation of the new function > if they wish. There should also be execution tests that the new function > works correctly at runtime (with different alignment, arguments just > before unmapped pages, etc., as with other string function tests). If the > new function is purely an ABI, not an API, it doesn't need user manual > documentation, however (although there will at least need to be a comment > giving the detailed semantics that were agreed on libc-coord). > > Is there some documentation for how to effectively use build-many-glibcs.py I've tried: $> python3 src/glibc/scripts/build-many-glibcs.py /some/were checkout gcc-vcs-11 $> python3 src/glibc/scripts/build-many-glibcs.py /some/were host-libraries $> python3 src/glibc/scripts/build-many-glibcs.py /some/were compilers $> python3 src/glibc/scripts/build-many-glibcs.py /some/were glibcs With GLIBC master I'm seeing a ton of failures so I'm not sure how I'm supposed to actually test my patches. I've also tried with gcc-vcs-mainline although my guess is that it will just be a less stable version that could cause unrelated failures. > -- > Joseph S. Myers > joseph@codesourcery.com >