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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, 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 (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3432C1F4B5 for ; Mon, 11 Nov 2019 22:53:06 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=LpOVz zjXSJcA/cSP/1nXBseDi5ZGByMiYU+jq3R7oz6itmOlZvF21WQCFdySqG2ifn1gE tFG1D/DQqv7XSqA3M4AsgO2M9sp+CbTqPlb+iJkxGOGimy8qWqwXgAiwP13JHBsR m8vH88gTH4x9e0f/K/TcjFx3G3JsqK14zhsLGw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=8VJVovNW0tx A087+/AP+OlVY8ug=; b=CDDahwF7DeWnPIB6lZpieEWxJIfu9bcjGhCc5zZHCPw pdyykxPzQFK5XMkf2/i5YJlo8b6q/wpGIsdR9p+PvTpwSnZ0MDMnL7a40i7zL644 PTtoVEx6Z5EYCCL32G6gp5z6rlm/7Er2fqdMgvkTH7yhedOigSXcruB6GNZInvWI = Received: (qmail 29462 invoked by alias); 11 Nov 2019 22:53:03 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 29445 invoked by uid 89); 11 Nov 2019 22:53:03 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: esa1.mentor.iphmx.com IronPort-SDR: QEpTg2y5xMlEjpNSkOeBLr6ccOkViiYHo7/oKp9/hSd4Tkb5I2UtzNNB0/bdOpXh13n+bDtqAd oO6Gv+Lv9sVdHabILLSrUbRJGFDAaYQNx8FnHsatYobSwBmti3vdw4ydvE6+gq9ABml90Upp2S UTX79u5I2oqPpawYrkTE1VuB7y4wpMNytcPmn/IsJDSa0diOja3GgWnY+ULzxSsADUkRfg7HZa u+HWE87TIRAmd4+ygMSUq8axAjIS1FgSec5feCdkLnLIsqeHnr17Qa7T0nGHJYqT2Ma7l/LHbx DeE= IronPort-SDR: aH5Ei5oUIqB2wVW+LUeq/tB73MoeqzJxmpJOhGuaGjKFHOY+99r9/tm/ylEaoUF7db5Itm6DwV gxbZuW3NHQ2U1LqOy5Is2ZpW20ly57W+CI0Z94uFGKmr4xWMWv8KQF0XZlw1SKjip08qS8PVKr dyALJDl0F50o6Pgxs8Sywaxom0lRYMajRld7v+FkFlyatonK1JR/OA8IbC5gfmUpRj1n/3lgxH pkNj+rc73mwuL6NfTwAOTC87FWLgRwLDWJLIoUFq5H5gwcXPwak9w2uDABYWwOQL6m39uon2RA JWA= Date: Mon, 11 Nov 2019 22:52:55 +0000 From: Joseph Myers To: Vineet Gupta CC: "libc-alpha@sourceware.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH] ieee754/dbl-64: Reduce the scope of temporary storage variables In-Reply-To: <7d22a532-6f19-6b43-2e7a-f6087f658606@synopsys.com> Message-ID: References: <20191111194349.21813-1-vgupta@synopsys.com> <7d22a532-6f19-6b43-2e7a-f6087f658606@synopsys.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-2128764594-1573512775=:30786" ---1152306461-2128764594-1573512775=:30786 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Mon, 11 Nov 2019, Vineet Gupta wrote: > On 11/11/19 2:33 PM, Joseph Myers wrote: > > On Mon, 11 Nov 2019, Vineet Gupta wrote: > > > >> Functionally it should not result in code gen changes and if at all > >> those would be better since the scope of those temporaries is greatly > >> reduced now > > This feels like the sort of thing where "should not result in code gen > > changes" should be tested by running build-many-glibcs.py --strip with > > unmodified glibc sources to build a full set of stripped glibc binaries, > > saving those binaries and then running build-many-glibcs.py --strip again > > and comparing the two sets of shared libraries (something I did a lot of > > when reworking how libm function aliases were defined; static libraries > > are expected to change because of timestamps, but shared library binaries > > can be usefully compared like this). If the two sets of stripped binaries > > are indeed identical, that is strong evidence that the patch is safe; > > otherwise, review of the patch will require more detailed inspection of > > the types of the arguments to these macros, and the uses of the temporary > > variables, at every call site, to make sure that semantics aren't being > > changed. > > Ok Understand.  What arch(es) / build options would you want this tested for in > aforementioned way to get a reasonable confidence ? The suggestion is two full "build-many-glibcs.py --strip glibcs" runs (one before and one after the change, and comparing the resulting binaries), covering all architectures, if you have suitable fast hardware for doing such testing (it's quite time-consuming; a single run takes about 3 hours wall-clock time on a 16-core / 32-hardware-thread Haswell-based Xeon, for example). (A single "compilers" run can be used to build the compilers used for both those "glibcs" runs.) > > (In any case, please specify when submitting a patch how it was tested.) > > I've currently tested this with build-many-glibcs.py for ARC port only with and > w/o hard float support being worked on. If for whatever reason there *are* differences in the stripped glibc shared libraries, at least one full run of the glibc testsuite (including execution tests) for some architecture will be needed as well to verify that the generated code works correctly in at least one configuration. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-2128764594-1573512775=:30786--