Re: [whopr] Design/implementation alternatives for the driver and WPA

[Chris Lattner <clattner@apple.com>]

On Jun 5, 2008, at 6:59 AM, Ian Lance Taylor wrote:

> "Rafael Espindola" <espindola@google.com> writes:
>
>> Interesting. The use of lto_codegen_add_must_preserve_symbol is kind
>> of the opposite of what I had understood. What do you do in this  
>> case:
>>
>> a.o: IL file that contains a reference to "f"
>> b.o: IL file that has a weak def of "f"
>>
>> There is no strong definition. Can you inline f into the use in a.o?
>
> I don't know what LLVM does, but in principle, in ELF, you can do this
> inlining when linking an executable, but not when linking a shared
> library.  Actually, when linking a shared library, what matters is not
> whether the definition of "f" is weak or not, but what the visibility
> of 'f" is (default, hidden, protected, or internal).  And, of course,
> the visibility of "f" can be set by link-time options (e.g.,
> -Bsymbolic).

In LLVM LTO, the model is that the linker is the one that knows about  
visibility.  The problem is that 'hidden' is not sufficient to capture  
visibility info when mixing LTO modules with native ones.  If you  
have: [a-c].c and compile [ab].c with LTO and c.c without, any hidden  
symbols should be visible outside the [ab].o LTO region.

LLVM LTO handles this by marking symbols "internal" (aka static, aka  
not TREE_PUBLIC, whatever) when the symbol is not visible outside the  
LTO scope.  This allows the optimizers to go crazy and hack away at  
the symbols, but only when safe.

'Weakness' only matters when a symbol is exported from the LTO scope,  
so 'weak' and 'visibility' are orthogonal.

-Chris