From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76353 invoked by alias); 15 Dec 2017 16:34:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 76340 invoked by uid 89); 15 Dec 2017 16:34:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=90OoSk0J7OBV1xeSp4DgJACdGXfzeZyeD8PtqJ2MxUE=; b=LCUVE4k5Yacerhd4zGJjDAZRPAKRzRi2A2Du5pE6Wm+SyMivltpx/55xLomiUAzdob sdUvLaLc4o58Pab4gD1m9p8tSJmAPDOjRo427kfflEI0RdgAV3pgQFgSJCYUk8ARkCt1 vZGIL2yeajb8VV1e/PtqT//h1nwhQTBXH8hvTcFInbG2wml8kxYgsYZOWy6x/hyIpEFK i3JW43QYo8hqhSut+gcZ126JpMZROIY3Y8vujfzoPM0Hp7tn+3ytOQc1Was/7JFhws/o TPnR6mXiQELOXeqPpR3wY+LBtPJqTj7xRBTwsZQksiP7EeRHnfAN3anjZ3NXiHCzAvec 1BAA== X-Gm-Message-State: AKGB3mJiFnf61DqFxwvI8J0/I6Sdhp0pz5sjauhtxmEEXoJdX37ghhKN 2vYtsz8ChQjdFCvT5N9TP9uooXRe2sHriV4ZF2U= X-Google-Smtp-Source: ACJfBosUxp9SOpHD4AX2SCqCBFre2WEIwZAvTSAhaY92OXrNpoVovxPDrGQMnZIeJ5hxz65bFBkCUlMegLTAvAmkRF0= X-Received: by 10.157.9.196 with SMTP id 4mr8711152otz.173.1513355661674; Fri, 15 Dec 2017 08:34:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1513143801-3290-1-git-send-email-raji@linux.vnet.ibm.com> <1513143801-3290-2-git-send-email-raji@linux.vnet.ibm.com> From: "H.J. Lu" Date: Fri, 15 Dec 2017 16:34:00 -0000 Message-ID: Subject: Re: [PATCH 1/3] New generic sincosf To: Joseph Myers Cc: Rajalakshmi Srinivasaraghavan , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-12/txt/msg00493.txt.bz2 On Fri, Dec 15, 2017 at 8:24 AM, Joseph Myers wrote: > On Fri, 15 Dec 2017, H.J. Lu wrote: > >> On Fri, Dec 15, 2017 at 7:48 AM, Joseph Myers wrote: >> > On Fri, 15 Dec 2017, H.J. Lu wrote: >> > >> >> > glibc is build with -fmerge-all-constants, so constants should already be >> >> > shared at link time; making constants hidden would be relevant only for >> >> > arrays, not for individual floating-point numbers (and if the individual >> >> > constants aren't put in appropriate sections with link-time merging, it's >> >> > probably because not doing so is more efficient on a particular >> >> > architecture). >> >> >> >> What do you suggest for x86-64 to avoid array duplication? >> > >> > Well, a followup patch to refactor the arrays into hidden variables would >> > be reasonable once the sincosf patch is in - but it would need >> > benchmarking to make sure it doesn't adversely affect performance. >> >> Do you have any suspicions to indicate that hidden array may be >> slower than local one to access? > > On some architectures, GCC uses section anchors for access to variables > defined in the same source file. In such cases, moving the arrays to > being hidden and defined separately means that the address of each array > needs to be loaded separately because the offsets between different > variables are no longer known when the source files using them are being > compiled, whereas if defined in each source file, a function accessing > multiple arrays could load the anchor address and them compute all the > other addresses with small offsets from it. This won't show up on x86. > You should be able to avoid that problem by putting all the data in a > single structure, as done in e_exp2f_data.c, rather than separate hidden > variables. > Good to know. I have no objections now. I will prepare a patch after s_sincosf.c is checked in. Thanks. -- H.J.