This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH i386] Allow sibcalls in no-PLT PIC
- From: Rich Felker <dalias at libc dot org>
- To: Michael Matz <matz at suse dot de>
- Cc: Richard Henderson <rth at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Alexander Monakov <amonakov at ispras dot ru>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Wed, 20 May 2015 10:09:46 -0400
- Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqRBz7L6Fr1nxDVrTEh3EQ-AVV0dMCC0-xdpq87k=e4EQ at mail dot gmail dot com> <20150515204237 dot GF17573 at brightrain dot aerifal dot cx> <CAMe9rOp1ibVzf0KOt+1boOxb5ag85fe2Rv2Rst=CgAtOTGFBxA at mail dot gmail dot com> <20150515230810 dot GA73210 at kam dot mff dot cuni dot cz> <CAMe9rOr1_r0tvi_JdsCL8w-MMAqhSeVpA6sbksnn1yP224zn_A at mail dot gmail dot com> <20150515234403 dot GG17573 at brightrain dot aerifal dot cx> <alpine dot LSU dot 2 dot 20 dot 1505191637140 dot 27315 at wotan dot suse dot de> <20150519180659 dot GG17573 at brightrain dot aerifal dot cx> <555B87F4 dot 30908 at redhat dot com> <alpine dot LSU dot 2 dot 20 dot 1505201400400 dot 27315 at wotan dot suse dot de>
On Wed, May 20, 2015 at 02:10:41PM +0200, Michael Matz wrote:
> Hi,
>
> On Tue, 19 May 2015, Richard Henderson wrote:
>
> > 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.
>
> Well, hoisting always needs a register, and if hoisted out of a loop
> (which you all seem to be after) that register is live through the whole
> loop body. You need a register for each different called function in such
> loop, trading the one GOT pointer with N other registers. For
> register-starved machines this is a real problem, even x86-64 doesn't have
> that many. I.e. I'm not convinced that this hoisting will really be much
> 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:
anything where the majority of the callee's data is floating point and
thus kept in xmm registers. In that case register pressure is a lot
lower, and there's also an obvious class of cross-DSO functions calls
you'd be making over and over again: anything from libm.
Rich