>> 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