> 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?
We are still discussing how we are going to implement, so the API is still not final. Some things that have been pointed out: *) Plugins could have other uses and the naming used on the LLVM LTO interface is LTO specific. *) We have a normal symbol table on the .o files. It is not clear if we should assume that it will always be the case. If so, we don't need the API part that handles that. *) How do you handle the case of multiple symbols with the same name (say a weak and a strong one)? lto_codegen_add_must_preserve_symbol has a char* argument. How does it know which symbol we are talking about? *) To save memory, one option is to have the plugin exec WPA and WPA exec the linker again with the new objects. In this case the api should be a bit different. > -Chris > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
