This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH i386] Allow sibcalls in no-PLT PIC
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Michael Matz <matz at suse dot de>, 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: Tue, 19 May 2015 12:06:05 -0700
- Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC
- Authentication-results: sourceware.org; auth=none
- References: <20150515194824 dot GB14415 at kam dot mff dot cuni dot cz> <CAMe9rOr3yQv-+cJxwp_YfNY=9G+FnV6=JdYh_T6kPDJtSA0fzg at mail dot gmail dot com> <20150515202319 dot GE17573 at brightrain dot aerifal dot cx> <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>
On Tue, May 19, 2015 at 11:59 AM, Richard Henderson <email@example.com> wrote:
> 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.
My relax approach won't take away any optimization done by compiler.
It simply turns indirect branch into direct branch with a nop prefix at
link-time. I am having a hard time to understand why we shouldn't do it.