> > Actually I think it is harder than that, because we need to strip LTO data > > from the object files, so we do not end up with duplicated LTO if the object > > file was already having both LTO and non-LTO stuff in it. > > When I started with LTO I was looking into that, and that is why I originally > implemented slim LTO as a first step. But then I realized that that just > adding > the postfixes is much easier, after HJ proposed his linker based solution. > > Anyways can stay with the special binutils for the kernel for now, but it's > a bit of a pain for users to install them (user feedback is generally that > this is the hardest part) > > I'm a bit surprised that the programs you test (Firefox, LibreOffice etc.) > don't have .S files.
They don't do incermental linking. They build static libraries that works just fine. Indeed it would be nice to have things working in general. > > > > > I am not sure we can/want to implement this w/o some sort of support from > > plugin side. It would basically mean doing another incremnetal linker in the > > plugin. > > > > How does HJ's binutils work for fat LTO? > > I believe it works too (pretty sure I tested it at some point) > > Here's the original design spec > > https://sourceware.org/ml/binutils/2011-04/msg00404.html > Yep, i saw this a while ago, but forgot how to find it. Thanks! Now I remember that HJ's binutils has IR objects (which are slim or fat LTO) and mixed objects which are essentially two objects together. I suppose the IR linking I impleemnted should work just fine with HJ's approach and we could make lto-plugin to skip the path switching to early codegen. Over the current HJ's implementation the advantage is that you will get faster WPA at kernel link time. It would be nice to arrive with a solution for mainline bintutils. Honza
