Re: [PATCH i386] Allow sibcalls in no-PLT PIC

[Jan Hubicka <hubicka@ucw.cz>]

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