From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26675 invoked by alias); 3 Feb 2015 21:20:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 26664 invoked by uid 89); 3 Feb 2015 21:20:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail-vc0-f181.google.com Received: from mail-vc0-f181.google.com (HELO mail-vc0-f181.google.com) (209.85.220.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Feb 2015 21:20:29 +0000 Received: by mail-vc0-f181.google.com with SMTP id id10so17611446vcb.12 for ; Tue, 03 Feb 2015 13:20:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EPyJfn0KjuSrrEY/FIwAiS++lLxoA5Fe0qY4GTAYLX4=; b=aL4dOmO8gSP0uyeFEcH7cewgDq6ZgvKdHIy5p5dVKzr4BzjgXLGC3sNGWfohs1S3Q+ k4omp2dnafQ3LISlK8xxXluOEUSHnGiIj4ztYO9phcZTuIfo2PFyaVx7O5gcMJws6Y1a Pt/GJ5n0WQqGQTDOuwXPnn5Q9sbluX/RcH2WgTUj+9Xsg3INDPSgx8At1Snm2zWy+C6q JZdkxMhx7zWvLp3vozESGYpB0L/2ojUmY270537us88oTiy1F/mqAe8E8j/2FD5FVmhS XY6GMGMmAvLUzfmC/mZGUF9AAqyLTsYRf0nLr7Oh6I2ok8MRxVNbS77uPAbu4dRIH+rX ASCQ== X-Gm-Message-State: ALoCoQn0z3vo+9W0vUOw4M/EK4svmTQR52rYRVfQMQWfIwL5wXXd7LFFCoL6P4bK/Urg3ae0oofT MIME-Version: 1.0 X-Received: by 10.52.171.113 with SMTP id at17mr14633657vdc.58.1422998427520; Tue, 03 Feb 2015 13:20:27 -0800 (PST) Received: by 10.52.37.114 with HTTP; Tue, 3 Feb 2015 13:20:27 -0800 (PST) In-Reply-To: <20150203193615.GZ1746@tucnak.redhat.com> References: <20150203193615.GZ1746@tucnak.redhat.com> Date: Tue, 03 Feb 2015 21:20:00 -0000 Message-ID: Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations From: Sriraman Tallam To: Jakub Jelinek Cc: "H.J. Lu" , Uros Bizjak , "gcc-patches@gcc.gnu.org" , David Li , Cary Coutant Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00164.txt.bz2 On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek wrote: > On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote: >> This was the original patch to i386.c to let global accesses take >> advantage of copy relocations and avoid the GOT. >> >> >> @@ -13113,7 +13113,11 @@ legitimate_pic_address_disp_p (rtx disp) >> return true; >> } >> else if (!SYMBOL_REF_FAR_ADDR_P (op0) >> - && SYMBOL_REF_LOCAL_P (op0) >> + && (SYMBOL_REF_LOCAL_P (op0) >> + || (HAVE_LD_PIE_COPYRELOC >> + && flag_pie >> + && !SYMBOL_REF_WEAK (op0) >> + && !SYMBOL_REF_FUNCTION_P (op0))) >> && ix86_cmodel != CM_LARGE_PIC) >> >> I do not understand here why weak global data access must go through >> the GOT and not use copy relocations. Ultimately, there is only going >> to be one copy of the global either defined in the executable or the >> shared object right? >> >> Can we remove the check for SYMBOL_REF_WEAK? > > So, what will then happen if the weak undef symbol isn't defined anywhere? > In non-PIE binaries that is fine, the linker will store 0. > But in PIE binaries, the 0 would be biased by the PIE load bias and thus > wouldn't be NULL. Thanks for clarifying. > You can only optimize weak vars if there is some weak definition in the > current TU. Would this be fine then? Replace !SYMBOL_REF_WEAK (op0) with !(SYMBOL_REF_WEAK (op0) && SYMBOL_REF_EXTERNAL_P (op0)) Thanks Sri > > Jakub