>> In ELF you have to think about symbol overriding. Let's say you link
>> a.o b.o c.o. a.o has a reference to symbol S. b.o has a strong
>> definition. c.o has a weak definition. a.o and c.o have LTO
>> information, b.o does not. ELF requires that a.o call the symbol from
>> b.o, not the symbol from c.o. I don't see how to make that work with
>> the LLVM interface.
>
> This does work. There are two parts to it. First the linker's master
> symbol
> table sees the strong definition of S in b.o and the weak in c.o and
> decides to use the strong one from b.o. Second (because of that) the linker
> calls lto_codegen_add_must_preserve_symbol("S"). The LTO engine then
> sees it has a weak global function S and it cannot inline those. Put
> together
> the LTO engine does generate a copy of S, but the linker throws it away
> and uses the one from b.o.
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?
> -Nick
>
>
Cheers,
--
Rafael Avila de Espindola
Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland
Registered in Dublin, Ireland
Registration Number: 368047