Chris Lattner <[EMAIL PROTECTED]> writes: > Is there a specific reason you don't use the LLVM LTO interface? It > seems to be roughly the same as your proposed interface: > > a) it has a simple C interface like your proposed one > b) it is already implemented in one system linker (Apple's), so GCC > would just provide its own linker plugin and it would work on apple > platforms > c) it is richer than your interface > d) it is battle tested, and exists today > e) it is completely independent of llvm (by design) > f) it is fully documented: http://llvm.org/docs/LinkTimeOptimization.html > > Is there something specific you don't like about the LLVM interface?
(I didn't design the proposed linker interface, and I'm not sure my earlier comments were included in the proposal sent to the list. I'm going to reply to that next.) When I look at the LLVM interface as described on that web page, I see these issues, all fixable: * No support for symbol versioning. * The return value of lto_module_get_symbol_attributes is not defined. * lto_codegen_set_debug_model and lto_codegen_set_pic_model appear to be underspecified--don't they need an additional parameter? * Interfaces like lto_module_get_symbol_name and lto_codegen_add_must_preserve_symbol are inefficient when dealing with large symbol tables. A more general problem is that the main reason I see to use a linker plugin is to let the linker handle symbol resolution. The LLVM interface does not do that. Suppose the linker is invoked on a sequence of object files, some with with LTO information, some without, all interspersed. Suppose some symbols are defined in multiple .o files, through the use of common symbols, weak symbols, and/or section groups. The LLVM interface simply passes each object file to the plugin. The result is that the plugin is required to do symbol resolution itself. This 1) loses one of the benefits of having the linker around; 2) will yield incorrect results when some non-LTO object is linked in between LTO objects but redefines some earlier weak symbol. Also, returning a single object file restricts the possibilities. The design of WHOPR, as I understand it, permits creating several different object files in parallel based on a fast analysis of which code should be compiled together. When the linker supports concurrent linking, it will be desirable to be able to provide it with each object file as it is completed. Ian
