From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43562 invoked by alias); 19 May 2015 18:59:05 -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 43546 invoked by uid 89); 19 May 2015 18:59:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 May 2015 18:59:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4JIx2nC021572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 19 May 2015 14:59:03 -0400 Received: from anchor.twiddle.net (vpn-229-80.phx2.redhat.com [10.3.229.80]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4JIx11v021525; Tue, 19 May 2015 14:59:02 -0400 Message-ID: <555B87F4.30908@redhat.com> Date: Tue, 19 May 2015 19:03:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rich Felker , Michael Matz CC: "H.J. Lu" , Jan Hubicka , Alexander Monakov , GCC Patches , Uros Bizjak Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC References: <20150515194824.GB14415@kam.mff.cuni.cz> <20150515202319.GE17573@brightrain.aerifal.cx> <20150515204237.GF17573@brightrain.aerifal.cx> <20150515230810.GA73210@kam.mff.cuni.cz> <20150515234403.GG17573@brightrain.aerifal.cx> <20150519180659.GG17573@brightrain.aerifal.cx> In-Reply-To: <20150519180659.GG17573@brightrain.aerifal.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01742.txt.bz2 On 05/19/2015 11:06 AM, Rich Felker wrote: > I'm still mildly worried that concerns for supporting > relaxation might lead to decisions not to optimize code in ways that > would be difficult to relax (e.g. certain types of address load > reordering or hoisting) but I don't understand GCC internals > sufficiently to know if this concern is warranted or not. It is. The relaxation that HJ is working on requires that the reads from the got not be hoisted. I'm not especially convinced that what he's working on is a win. With LTO, the compiler can do the same job that he's attempting in the linker, without an extra nop. Without LTO, leaving it to the linker means that you can't hoist the load and hide the memory latency. > I would still like to see the @GOTPCREL stuff added and used instead > of @GOT, as I mentioned earlier in the thread, but I agree that's > independent of relaxation support and shouldn't block it. I don't think that @GOTPCREL for 32-bit is a good idea. This is the scheme that Darwin uses, so we do have some experience with it. In order for it to work you've got to have a pointer to a random address in the function. It means that you can only "easily" compute the address once. If you need the value again you wind up with the same "extra" addl insn that we have with the current GOT pointer. We've just started to do inter-function register allocation. The next step along those lines is to share the computation of GOT between multiple functions. At which point it really helps to have one global base address to talk about. r~