>> 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. -Andi
