Partial LTO?

Posted Aug 22, 2012 13:23 UTC (Wed) by nix (subscriber, #2304)
In reply to: Partial LTO? by jzbiciak
Parent article: Link-time optimization for the kernel

It's just ld -r, and it's done in every directory in the kernel tree (that has any .o files in it at all), generating either module.o or built-in.o files that are then linked together to generate final modules or the kernel proper (though the kernel proper also has a bunch of other object files, most of the bulk is in built-in.o files). The LTO sections should get carried along with this, and then at full link time the linker plugin should pick them up and do a full LTO.

to post comments

Partial LTO?

Posted Aug 22, 2012 14:22 UTC (Wed) by jzbiciak (guest, #5246) [Link]

I kinda figured it was something such as by-directory (it certainly appeared that way last time I built a kernel). I was pretty sure the normal flow carried the serialized GIMPLE down to the end for the final LTO. Where the boundary becomes important is if you try to implement cesarb's partial-LTO suggestion.

If you did a "partial LTO", where you munged all the GIMPLE together and generated a new object in place of the partially linked library, and didn't pass the GIMPLE up to the next level, you'd be leaving many of the most interesting optimizations aside if many come from optimizing library and core code into the bodies of drivers and other leaves.

It doesn't make sense to re-codegen at partial link time unless your intent is to throw away the GIMPLE, or provide a library that could be linked both with and without further LTO (which seems... weird?).