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=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 73DB61F8C6 for ; Tue, 14 Sep 2021 02:06:02 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 504BE385842B for ; Tue, 14 Sep 2021 02:06:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 504BE385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1631585161; bh=5T763kLuQuhwG8f14cDY4gcAzc4314rODDrIVRycmhI=; 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=qlkrnvExvUDNzhPSi47AdmcEItvcucEnMtZOkIoUy8AbZa9MUtAg8TMneFe2gaW0c a2O4Q62mNETq1vy9x43ZF4seMO/roMZtIid+d6lXa5y1V9NGGz64nkKBVSXKYKy/Wx 9Pltd6yefOfnh4ziJr8lAfwbd74ncmAXOXRRZTA8= Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id C44643858402 for ; Tue, 14 Sep 2021 02:05:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C44643858402 Received: by mail-pg1-x535.google.com with SMTP id t1so11236410pgv.3 for ; Mon, 13 Sep 2021 19:05:41 -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=YMr32BERm3Og5dUcgovS8gTMWd7QGFYJSEUbGvLZtSA=; b=Jub87FEru2QzAlT2CrGJg70/Av7+vVag37/aqNdpn5MkZd18uWUY8YrRBBetsULPjH kI5RTYcn1ahA+bYB8ewrtLp6DF+B+FuQPSu1hI3bHWRxu/eq5bKAWNTTPwkYhP8BGpeZ 5So49UsTvaewWjjAOSZwOUIZTpBg+I+V42nrC0nTH6IitPVuFD7Yz0E2EAGwFC2dEhsY KnOVyxFs6W+/OPDGWCEJTsn/Qa2UM1NeqhJCZDraqvKcCkoqEXORA8gvddFweWOaObac RDx8R72D+8J5zdk/Xi0DV2V5wtj8g6Ue8NV4+Ww8mKyRrAwiXT5T185M8uHy8dpN76tX MOdA== X-Gm-Message-State: AOAM532faInvdhD7S2eEGwAtXxuLeISCDCp3TkrfczePHd43R6o6Jxe6 D0IA+8HGpMJcbuFkNEfNpP+INhdrHx5Qv0QWt7g= X-Google-Smtp-Source: ABdhPJwzFz2ltdjuh/x7R5tj/amkxo49o4RQ35mhVsJF1bl2oCA2mls9BNhRbJAi7jomXfmi5fLq4HtGWAEuAWZqb7U= X-Received: by 2002:a63:798f:: with SMTP id u137mr13605739pgc.321.1631585140775; Mon, 13 Sep 2021 19:05:40 -0700 (PDT) MIME-Version: 1.0 References: <20210913230506.546749-1-goldstein.w.n@gmail.com> <20210913230506.546749-5-goldstein.w.n@gmail.com> <2ca0771e-2d1d-c0dd-ac98-8f6946d7b469@redhat.com> In-Reply-To: <2ca0771e-2d1d-c0dd-ac98-8f6946d7b469@redhat.com> Date: Mon, 13 Sep 2021 21:05:30 -0500 Message-ID: Subject: Re: [PATCH 5/5] x86_64: Add evex optimized bcmp implementation in bcmp-evex.S To: "Carlos O'Donell" 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: GNU C Library Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Mon, Sep 13, 2021 at 8:18 PM Carlos O'Donell wrote: > On 9/13/21 7:05 PM, Noah Goldstein via Libc-alpha wrote: > > No bug. This commit adds new optimized bcmp implementation for evex. > > > > The primary optimizations are 1) skipping the logic to find the > > difference of the first mismatched byte and 2) not updating src/dst > > addresses as the non-equals logic does not need to be reused by > > different areas. > > > > The entry alignment has been fixed at 64. In throughput sensitive > > functions which bcmp can potentially be frontend loop performance is > > important to opimized for. This is impossible/difficult to do/maintain > > with only 16 byte fixed alignment. > > > > test-memcmp, test-bcmp, and test-wmemcmp are all passing. > > This series fails in the containerized 32-bit x86 CI/CD regression tester. > > https://patchwork.sourceware.org/project/glibc/patch/20210913230506.546749-5-goldstein.w.n@gmail.com/ Shoot. AFAICT the first error is: *** No rule to make target '/build/string/stamp.os', needed by '/build/libc_pic.a'. I saw that issue earlier when I was working on just supporting bcmp for the first commit: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex So I think I missed/messed up something there regarding the necessary changes to the Makefile/build infrastructure to support the change. While it doesn't appear to be an issue on my local machine I left the redirect in string/memcmp.c: https://sourceware.org/git/?p=glibc.git;a=blob;f=string/memcmp.c;h=9b46d7a905c8b7886f046b7660f63df10dc4573c;hb=HEAD#l360 But was one area where I didn't really know the right answer. Does anyone know if there is anything special that needs to be done for the 32 bit build when adding a new implementation? Also, does anyone know what make/configure commands I need to reproduce this on a x86_64-Linux machine? The build log doesn't appear to have the command. For my completely fresh build / testing I ran: rm -rf /path/to/build/glibc; mkdir -p /path/to/build/glibc; (cd /path/to/build/glibc/; unset LD_LIBRARY_PATH; /path/to/src/glibc/configure --prefix=/usr; make --silent; make xcheck; make -r -C /path/to/src/glibc/string/ objdir=`pwd` check; make -r -C /path/to/src/glibc/wcsmbs/ objdir=`pwd` check) which doesn't appear to have cut it. > > -- > Cheers, > Carlos. > >