On Tue, Dec 7, 2010 at 4:20 PM, Andi Kleen <a...@firstfloor.org> wrote: >>> Here is my proposal. Any comments? >> >> We talked about ld -r a while back during the WHOPR project, and the >> two ways that the linker could work: (1) combine all the .o files and >> use the plugin to run LTRANS on the IR files, producing a pure, >> optimized, object file; and (2) combine the non-IR object files as ld >> -r normally would, and combine that result somehow with the IR from >> the other files, for later optimization. If I remember correctly, >> there was support for both modes of operation. The first mode is >> easily handled with the current design (untested as far as I know -- >> there are probably bugs, and I'm not sure if we get the symbol >> visibility correct in those cases). > > the first mode is imho useless because you'll never get whole program > optimizations this way. I tested it some time ago and it worked in a > limited way > (there were some problems that gcc crashed if you didn't specify > -fwhole-program which would be obviously a lie, but those might be fixed > now) > But it won't give you the LTO advantages in any case. > > I implemented (2) by giving the sections appropiate names > so they don't get messed up. this works today with gcc mainline, as > long as all objects in the combined object are LTO. > > 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. >
My proposal should address mixing of lto and non lto objects. -- H.J.
