Hi Jan, I think this is a very good example where we could all collaborate (including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit more context. I'm copying him because he (and I believe Diego) had more contact with LTO than I had. If I got it right, LTO today: - needs the drivers to explicitly declare the plugin - needs the library available somewhere - may have to change the library loading semantics (via LD_PRELOAD) Since both toolchains do the magic, binutils has no incentive to create any automatic detection of objects. The part that I didn't get is when you say about backward compatibility. Would LTO work on a newer binutils with the liblto but on an older compiler that knew nothing about LTO? Your proposal is, then, to get binutils: - recognizing LTO logic in the objects - automatically loading liblto if recognized - warning if not I'm assuming the extra symbols would be discarded if no library is found, together with the warning, right? Maybe an error if -Wall or whatever. Can we get someone from the binutils community to opine on that? cheers, --renato On 11 February 2014 02:29, Jan Hubicka <hubi...@ucw.cz> wrote: > One practical experience I have with LLVM developers is sharing experiences > about getting Firefox to work with LTO with Rafael Espindola and I think it > was > useful for both of us. I am definitly open to more discussion. > > Lets try a specific topic that is on my TODO list for some time. > > I would like to make it possible for mutliple compilers to be used to LTO a > single binary. As we are all making LTO more useful, I think it is matter of > time until people will start shipping LTO object files by default and users > will end up feeding them into different compilers or incompatible version of > the same compiler. We probably want to make this work, even thought the > cross-module optimization will not happen in this case. > > The plugin interface in binutils seems to do its job well both for GCC and > LLVM > and I hope that open64 and ICC will eventually join, too. > > The trouble however is that one needs to pass explicit --plugin argument > specifying the particular plugin to load and so GCC ships with its own > wrappers > (gcc-nm/gcc-ld/gcc-ar and the gcc driver itself) while LLVM does similar > thing. > > It may be smoother if binutils was able to load multiple plugins at once and > grab plugins from system and user installed compilers without explicit > --plugin > argument. > > Binutils probably should also have a way to detect LTO object files and > produce > more useful diagnostic than they do now, when there is no plugin claiming > them. > > There are some PRs filled on the topic > http://cygwin.com/frysk/bugzilla/show_bug.cgi?id=15300 > http://cygwin.com/frysk/bugzilla/show_bug.cgi?id=13227 > but not much progress on them. > > I wonder if we can get this designed and implemented. > > On the other hand, GCC current maintains non-plugin path for LTO that is now > only used by darwin port due to lack of plugin enabled LD there. It seems > that liblto used by darwin is losely compatible with the plugin API, but it > makes > it harder to have different compilers share it (one has to LD_PRELOAD liblto > to different one prior executing the linker?) > > I wonder, is there chance to implement linker plugin API to libLTO glue or add > plugin support to native Darwin tools? > > Honza
