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: Jan Hubicka <hubicka at ucw dot cz>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Rich Felker <dalias at libc dot org>, 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: Sat, 16 May 2015 01:08:10 +0200
- Subject: Re: [PATCH i386] Allow sibcalls in no-PLT PIC
- Authentication-results: sourceware.org; auth=none
- References: <1430757479-14241-1-git-send-email-amonakov at ispras dot ru> <1430757479-14241-5-git-send-email-amonakov at ispras dot ru> <alpine dot LNX dot 2 dot 11 dot 1505151927170 dot 22867 at monopod dot intra dot ispras dot ru> <CAMe9rOq+gfTcCoY4AKefkZgysHr_XXOaCtOFWDro8OeT+mBUWQ at mail dot gmail dot com> <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>
Hello,
>
> There are codes like
>
> extern void foo (void);
>
> void
> bar (void)
> {
> foo ();
> }
>
> Even with LTO, compiler may have to assume foo is external
> when foo is compiled with LTO.
This is not exactly true if FOO is defined in other translation unit
compiled with LTO and hidden visibility.
OK, so as I get it, we get the following cases:
1) compiler knows it is generating call to a local symbol a current
unit (binds_to_current_def_p returns true).
We handle this correctly by doing IP relative call.
2) compiler knows it is generating call to a local symbol in DSO
(binds_local_p return true)
Currently I think this is only the -fno-pic case or case of explicit
hidden visibility and in this case we do IP relative call.
We may want to propose plugin API update adding PREVAILING_DEF_EXP.
So copiler would be able to default to this case for PREVAILING_DEF
and we will also catch cases where the symbol is defined in current
DSO as weak symbol, but the definition is not LTO.
This would be also way to communicate -Bsymbolic[-functions] across
the plugin API.
3) compiler knows there is going to be definition in the current DSO
(by seeing a COMDAT function body or resolution info) that is interposable
but because the function is inline or -fno-semantic-interposition happens,
the semantics will not change.
In this case it would be nice to arrange IP relative call to the
hidden alias. This may require an extension both on compiler and linker
side.
I was thinking of doing so for comdats by adding hidden alias with
fixed mangling, like __gnu_<function>.hiddenalias, and referring it.
But I think it is not safe as linker may throw away section that
is produced by GCC and prevail section that is not leaving to an undefined
symbol?
I think this is rather common case in C++ (never made any stats) because
uninlined comdats are quite common.
4) compiler has no clue but linker may know better
Here we traditionally always produce a PLT call. In cases the call
is known to be hot in the program it makes sense to trade lazy binding
for performance and produce call via GOT reference (-fno-plt).
I also see that H.J.'s branch helps us to actually avoid the GOT
reference in cases the symbol ends up binding locally. How the lazy
binding with relaxation works?
We may try to communicate down the information whether the symbol can
or can not semantically interpose to the linker, so it can do
-Bsymbolic by default for inline and COMDAT functions.
Actually perhaps the linker can just default to this for all comdat
defined symbols?
I think it still make sense to work on non-LTO codegen improvements.
As much as I would like everyone to LTO and FDO, most people don't.
5) Compiler knows it is generating call to external function.
We do not special case this, but we could add binds_external_p and
make it to determine this case from resolution info during LTO.
I do not see if this case is any different from 4 from PIC codegen
perspective except that perhaps the relax relocation will allow us to lazy
bind?
Honza