From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82505 invoked by alias); 20 May 2015 14:19:58 -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 82496 invoked by uid 89); 20 May 2015 14:19:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 20 May 2015 14:19:57 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B5EA4AD08; Wed, 20 May 2015 14:19:53 +0000 (UTC) Date: Wed, 20 May 2015 14:33:00 -0000 From: Michael Matz To: Rich Felker cc: Richard Henderson , "H.J. Lu" , Jan Hubicka , Alexander Monakov , GCC Patches , Uros Bizjak Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC In-Reply-To: <20150520140946.GU17573@brightrain.aerifal.cx> Message-ID: References: <20150515204237.GF17573@brightrain.aerifal.cx> <20150515230810.GA73210@kam.mff.cuni.cz> <20150515234403.GG17573@brightrain.aerifal.cx> <20150519180659.GG17573@brightrain.aerifal.cx> <555B87F4.30908@redhat.com> <20150520140946.GU17573@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg01841.txt.bz2 Hi, On Wed, 20 May 2015, Rich Felker wrote: > > of a win that often, outside toy examples. Sure, the compiler can hoist > > function addresses trivially, but I think it will lead to spilling more > > often than not, or alternatively the hoisting will be undone by the > > register allocators rematerialization. Of course, this would have to be > > measured for real not hand-waved, but, well, I'd be surprised if it's not > > so. > > The obvious example where it's useful on x86_64 is a major class: Yes, I can construct all kinds of examples where it's useful. That doesn't touch the topic of real-world cases or hard numbers actually comparing the number of hoisted callee addresses, the number that stay hoisted until after register allocation and the number of spills added by hoisting, on some relevant code base, like gcc itself, or SPEC. > anything where the majority of the callee's data is floating point and > thus kept in xmm registers. This code tends to work on multiple arrays in practice, and hence integer registers are required for all the addresses and offsets and loop counters. > In that case register pressure is a lot lower, Register pressure on x86 is never low :) Yes, x86-64 and others are much better in this regard. > and there's also an obvious class of cross-DSO functions calls you'd be > making over and over again: anything from libm. Ciao, Michael.