From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) by sourceware.org (Postfix) with ESMTPS id 54C2F385AC1E for ; Thu, 16 Sep 2021 22:17:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54C2F385AC1E Received: by mail-il1-x136.google.com with SMTP id x2so8154840ila.11 for ; Thu, 16 Sep 2021 15:17:29 -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=ore8Ashe43hMJUbv9VcyvshRnapzmGDVVn8Md0ZlbUI=; b=02ykkOeQe3mNCvvJwEjXKXSFCcKZVmfWGZkx8g6Kj9bjZfYrLvlx7xBC5GiJN5CiuI B+ZM/1uAUmj7QuhLuh6St0TjV1OtlSBicAjdCuKOcD/dx6f4NSbIYeDyUVHy4PSGLKBZ 98Is1gZ+UZ/hq3+CpR9wwlyhOvHrsUGzDtr1xBJ9+2IC6Gb/d6cUh9QTWP0plnpy3twS Ih1EoFJ3X9S2ttCNu0RrjUhX+TepCRBJ98/YAa/mJ1RdYdBprCfS8TsFmPX0VuLQB+3v RzScBG0y6TjaoCLXhXTD8BMcjvMxHNeAeVrE0/2vJgG5iKmBrPN/vBsE9HKloCzf6WAd nCcQ== X-Gm-Message-State: AOAM532gFSMsXwLqjdB1hWG5PC6Fl1nZHlWBw9cI0T/a+L4CtQq2POzp lmniW34AA1S5GHIQqqn3hc5OGBEDHRbIuMMFSzLak0+xa5E= X-Google-Smtp-Source: ABdhPJwY/BiAXPP4Q+Cc4Qhfe1zpxwzYzlFvZln2BE1mTPVyzcnIzr3UHG23Od+NgAFtYT2XHuc5BpTPG5CLlG97X4U= X-Received: by 2002:a92:c0c4:: with SMTP id t4mr5694735ilf.235.1631830648445; Thu, 16 Sep 2021 15:17:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Kennelly Date: Thu, 16 Sep 2021 18:17:17 -0400 Message-ID: Subject: Re: [libc-coord] Add new ABI '__memcmpeq()' to libc To: libc-coord@lists.openwall.com Cc: GNU C Library , gcc@gcc.gnu.org X-Spam-Status: No, score=-16.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, KAM_STORAGE_GOOGLE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_SBL_A, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no 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: Thu, 16 Sep 2021 22:17:30 -0000 On Thu, Sep 16, 2021 at 5:50 PM enh wrote: > plus testing for _equality_ can (as mentioned earlier) have slightly > different properties from the three-way comparator behavior of > bcmp()/memcmp(). > llvm-libc's implementation only returns the boolean, though. The mem* functions are extremely sensitive to instruction cache effects, so having 3 unique implementations (__memcmpeq, bcmp, memcmp) that do similar, but subtly different things can be a hidden performance cost--one that is hard to demonstrate with a microbenchmark. Our experience developing optimized mem* routines ended up showing better performance in actual applications when we accepted seemingly worse microbenchmark performance by optimizing for code footprint instead (more extensive notes for mem* in general and memcmp specifically (section 4.4) ). The alternative would be to alias (as the NOTES suggest as a possible implementation), but I think that raises James' question of why not just use bcmp? Dependencies on non-boolean implementations of bcmp seem rare--namely, I haven't actually seen one. > On Thu, Sep 16, 2021 at 2:43 PM Joseph Myers > wrote: > >> On Thu, 16 Sep 2021, James Y Knight wrote: >> >> > Wouldn't it be far simpler to just un-deprecate bcmp? >> >> The aim is to have something to which calls can be generated in all >> standards modes. bcmp has never been part of ISO C; there's nothing to >> undeprecate there. > > >> -- >> Joseph S. Myers >> joseph@codesourcery.com >> >