From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id 040073858D20 for ; Mon, 7 Feb 2022 13:30:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 040073858D20 Received: by mail-oi1-x235.google.com with SMTP id v67so16901617oie.9 for ; Mon, 07 Feb 2022 05:30:47 -0800 (PST) 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=82e1L24Ri0TzrKNjIBGNlgkd4QFP8mKCSPWOGVqsY5A=; b=kuJbj8lq1DY3Bc7KOoWdVvJxTXBruHOR3qM2Woh3wfTDR1CJt/5u2RcpWshj7uQ2B0 IEJO9CPOFEEv8S/wI2skflkfF4/w1UDASNf7l6MLNeYp9sWHqQJegrCIirWCF2jCrgpb 37dpFEPqgjL2WinQPbgYGqmcAvqI4jlFHa/2DMf1g8E4PqgwwKaLNf5GGCaTXsfs6gYm 09oDSD7o9OvrfVV6GjDp4sYk7lrG8zFOeAwE1iKu7OSpnDg9C7EJzXN09XSOnRbCbfjh nbvCcy13nTJA9kUSRKJ9oNulCrKrTm2T1Je4M7TM4ucKkKruVV/uvL2uqtlXHPOQzRsV scqg== X-Gm-Message-State: AOAM530uGJIh0qay+2ZsAuzrqoZDnLtm7ybxKU4zBrXOfljeOuPH4VwD IDYe5U3hh/JBcRQ8ICHyBG5ISw== X-Google-Smtp-Source: ABdhPJylXGVlqPeaW8JCpc5v5wKrN+KysKZ+7ZhrCuoRahRsy81WUp+5N9xdzCCn6iKiqmtHSvQHQQ== X-Received: by 2002:a05:6808:1154:: with SMTP id u20mr7204942oiu.169.1644240647266; Mon, 07 Feb 2022 05:30:47 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:733:4cdc:e08a:54c6:5108? ([2804:431:c7ca:733:4cdc:e08a:54c6:5108]) by smtp.gmail.com with ESMTPSA id m7sm3929014ots.32.2022.02.07.05.30.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Feb 2022 05:30:46 -0800 (PST) Message-ID: <14db2006-daf6-903c-f750-0db19842a46a@linaro.org> Date: Mon, 7 Feb 2022 10:30:44 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] elf: Replace memcmp with __memcmpeq for variable size Content-Language: en-US To: "H.J. Lu" , Florian Weimer Cc: "H.J. Lu via Libc-alpha" References: <20220206210914.1593336-1-hjl.tools@gmail.com> <874k5b3afx.fsf@mid.deneb.enyo.de> <87tudbklhm.fsf@oldenburg.str.redhat.com> <87sfsuak62.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 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, T_SCC_BODY_TEXT_LINE 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: Mon, 07 Feb 2022 13:30:50 -0000 On 07/02/2022 10:27, H.J. Lu via Libc-alpha wrote: > On Mon, Feb 7, 2022 at 5:19 AM Florian Weimer wrote: >> >> * H. J. Lu: >> >>>> This must be something else. According to the numbers, we save ~159 >>>> between ~569 cycles per __memcmpeq call. That is just not realistic. >>> >>> I removed the cycle info from the commit log. >> >> If we can't show the change is beneficial, is it worth the additional >> 1000 or so bytes in the loader text? >> > > $ LD_DEBUG=statistics elf/tst-relsort1 --direct > > does show improvements when __memcmpeq is called 24 times. > But the cycle number changes for each run. The overall trend is > faster. It will be more obvious when memcmp is called more often. > My understanding is this optimization would eventually be implemented by the compiler, so maybe it would be better to let it optimize if suitable (similar to what we are aiming for math code).