From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3735 invoked by alias); 10 May 2015 17:07:23 -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 3723 invoked by uid 89); 10 May 2015 17:07:23 -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,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: atrey.karlin.mff.cuni.cz Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 10 May 2015 17:07:22 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id CEFC481FA7; Sun, 10 May 2015 19:07:19 +0200 (CEST) Date: Sun, 10 May 2015 17:07:00 -0000 From: Jan Hubicka To: Rich Felker Cc: Jeff Law , Jakub Jelinek , Alexander Monakov , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Expand PIC calls without PLT with -fno-plt Message-ID: <20150510170719.GJ9659@atrey.karlin.mff.cuni.cz> References: <1430757479-14241-1-git-send-email-amonakov@ispras.ru> <1430757479-14241-6-git-send-email-amonakov@ispras.ru> <5547AD8D.9080806@redhat.com> <20150504173955.GE1751@tucnak.redhat.com> <5547AF7C.9030500@redhat.com> <20150506030834.GI17573@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150506030834.GI17573@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00858.txt.bz2 > On Mon, May 04, 2015 at 11:42:20AM -0600, Jeff Law wrote: > > On 05/04/2015 11:39 AM, Jakub Jelinek wrote: > > >On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote: > > >>On 05/04/2015 10:37 AM, Alexander Monakov wrote: > > >>>This patch introduces option -fno-plt that allows to expand calls that would > > >>>go via PLT to load the address of the function immediately at call site (which > > >>>introduces a GOT load). Cover letter explains the motivation for this patch. > > >>> > > >>>New option documentation for invoke.texi is missing from the patch; if this is > > >>>accepted I'll be happy to send a v2 with documentation added. > > >>> > > >>> * calls.c (prepare_call_address): Transform PLT call to GOT lookup and > > >>> indirect call by forcing address into a pseudo with -fno-plt. > > >>> * common.opt (flag_plt): New option. > > >>OK once you cobble together the invoke.texi changes. > > > > > >Isn't what Michael/Alan suggested better? I mean as/ld/compiler changes to > > >inline the plt slot's first part, then lazy binding will work fine. > > I must have missed Alan/Michael's message. > > > > ISTM the win here is that by going through the GOT, you can CSE the > > GOT reference and possibly get some more register allocation > > freedom. Is that still the case with Alan/Michael's approach? > > There are many advantages to 'going through the GOT'. CSE'ing the > reference is just one. The biggest (IMO) is that you can avoid the bad > PLT ABI that most targets have, where making a call to a PLT slot > requires the GOT address to be pre-loaded into a fixed, call-saved > register. This precludes sibcalls and forces many functions which > otherwise would not need their own stack frames to create one for > saving the old value of the GOT register. See my blog entry on the > topic here: http://ewontfix.com/18/ One common pattern I noticed while looking at codegen for speculative devirtualization is that in case we do not inline the virtual call we end up with if (ptr = &foo) foo() which leads to both GOT lookup to figure out address of foo and call across PLT. It would be nice to handle this gratefully. Note that one of improvements I want to do to devirt machinery is to change the code seuqence to: if (vptr == &expected_vtable) foo () else vptr[token](); To saven the vtable lookup. But this is not possible in all cases - it happens that there are multiple predicted vtables all agreeeing on the partiuclar slot. Honza > > Anyone who really wants lazy binding can use -fplt (which is > presumably still the default; I didn't check) but lazy binding should > largely be considered deprecated anyway since effective use of relro > protection requires -z now too, in which case you're paying all the > costs (which are considerable!) for lazy binding support even though > you won't get it. > > Rich