On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant <ccout...@google.com> 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).
We considered it. The problem is LTO performs the best when generating the final executable/DSO. That is we want the full IR in the output of "ld -r". > The second mode corresponds with your proposal here. It's complicated > by the fact that it's difficult to tell, once the objects are > combined, which compiled code came without corresponding IR. For this, > I've got a suggestion that seems a bit simpler than your > ".objectonly\004" section, based on an idea for something completely > unrelated[1] that I've been pondering over for a while. Instead of > embedding the non-IR objects into the mixed object file, let's instead > produce an archive file with several members: one that contains the > result of running ld -r on the non-IR objects in the link, and one > member for each of the IR files (alternatively, exactly one member > that contains the result of running ld -r on all of the IR objects). > In order to make the archive such that a subsequent link loads all of > the members unconditionally, I propose to add a special symbol > ".FORCE" into the archive symbol table for each member; when the > linker sees that symbol in the archive symbol table, it will load the > corresponding member unconditionally. > >> ○ Object-only section: >> § Section name won't be generated by any tools, something like >>".objectonly\004". >> § Contains non-IR object file. >> § Input is discarded after link. > > Please -- use a special section type, not a magic name. > As Dave pointed out, we need the magic section name for non-ELF platform. One main feature of my proposal is transparent: # ld -r -o foo.o foo1.o foo2.o foo3.o ... # ld -r o -bar.o bar1.o bar2.o bar3.o ... ... # ld -r o new.o foo.o bar.o ... where foo.o, bar.o ... are mixed object files. That is more user-friendly. Projects like Linux kernel can take advantage of LTO with simple changes to their Makefiles. -- H.J.
