Now copying Rafael, which can give us some more insight on the LLVM LTO side.
cheers, --renato On 11 February 2014 09:55, Renato Golin <renato.go...@linaro.org> wrote: > 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
