From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31060 invoked by alias); 11 Nov 2015 16:41:10 -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 31050 invoked by uid 89); 11 Nov 2015 16:41:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Nov 2015 16:41:08 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1ZwYSH-0002Gz-00; Wed, 11 Nov 2015 16:41:05 +0000 Date: Wed, 11 Nov 2015 16:41:00 -0000 From: Rich Felker To: Oleg Endo Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH v4] SH FDPIC backend support Message-ID: <20151111164105.GX3818@brightrain.aerifal.cx> References: <20151021034138.GA4087@brightrain.aerifal.cx> <1445433471.5521.100.camel@t-online.de> <20151021201510.GV8645@brightrain.aerifal.cx> <20151023063221.GI8645@brightrain.aerifal.cx> <1445783331.8060.3.camel@t-online.de> <20151027024706.GU8645@brightrain.aerifal.cx> <1445954499.8060.22.camel@t-online.de> <20151110200700.GT3818@brightrain.aerifal.cx> <1447252586.3080.9.camel@t-online.de> <20151111145642.GV3818@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151111145642.GV3818@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01397.txt.bz2 On Wed, Nov 11, 2015 at 09:56:42AM -0500, Rich Felker wrote: > > > I'm actually > > > trying to prepare a simpler FDPIC patch for other gcc versions we're > > > interested in that's not so invasive, and for now I'm just having > > > function_symbol replace SFUNC_STATIC with SFUNC_GOT on TARGET_FDPIC > > > to > > > avoid needing all the label stuff, but it would be nice to find a way > > > to reuse the existing framework. > > > > Do you know how this affects code size (and inherently performance)? > > I suspect it makes very little difference, but to compare I'd need to > do the same hack on 5.2.0 or trunk. The only difference should be one > additional load per call, and one additional GOT slot per function > called this way (but just once per executable/library). Actually I think this is not quite right: if the call takes place via the GOT, this also requires the initial r12 to be preserved somewhere in order to load the function address, whereas for SFUNC_STATIC, the initial r12 can be completely discarded, right? (SFUNC functions are not permitted to use the GOT themselves as far as I can tell, and thus do not receive the hidden GOT argument in r12.) Rich