On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen <a...@firstfloor.org> wrote: >> On 12/07/2010 04:20 PM, Andi Kleen wrote: >>> >>> The only problem left is mixing of lto and non lto objects. this right >>> now is not handled. IMHO still the best way to handle it is to use >>> slim lto and then simply separate link the "left overs" after deleting >>> the LTO objects. This can be actually done with objcopy (with some >>> limitations), doesn't even need linker support.
I agree that FAT lto objects are not necessary to make the everything work and the integration of LTO with existing build environment 'transparent' --- there is compiler out in the world that does just that -- produces IL only objects (wrapped in elf format); works with archives with mixed objects; works with ld -r with mixed objects; builds unix kernel successfully with LTO ... David >>> >> >> Quite possibly a better way to deal with that is to provide a mechanism >> for encapsulating arbitrary binary code objects inside the LTO IR. > > Then you would need to teach your assembler and everything > else that may generate ELF objects to generate this magic object. But why > not just ELF directly? that is what it is after all. > > To be honest I don't really see the point of all this complexity you > guys are proposing just to save fat LTO. Fat LTO is always a bad idea > because it's slow and does lots of redundant work. If LTO is to become > a more wide spread mode it has to go simply because of the poor > performance. > > With slim LTO passthrough is very straight-forward: simple pass > through every section that is not LTO and generate code for the LTO > sections. No new magic sections needed at all. > > -Andi > >
