Mark Mitchell <[EMAIL PROTECTED]> writes: > http://gcc.gnu.org/projects/lto/lto.pdf
Section 2.2.1 (Variables and Functions) mentions C++ inline functions. It should also mention gcc's C language "extern inline" functions. The same section should consider common symbols. These appear as uninitialized definitions. Common symbols should normally be merged. Obviously the text referring to GNU attributes will need to be expanded. Some cases are not obvious; e.g., longcall. In section 3.3 (Assembler) I'll note that the PowerPC XCOFF assembler supports a .rename directive, which could be easily be made available for all targets. I'll also note that for non-GNU targets, we must be able to use the native assembler. Therefore, it may not always be possible to keep symbol names the same as source code names. That will have to be an option, fortunately one that only affects debugging information. In section 3.4 (Linker) I have the same comment: for non-GNU targets, the native linker is sometimes required, so modifying the linker should not be a requirement. And the exact handling of .a files is surprisingly target dependent, so while it would be easy to code an archive searcher in gcc, it would be tedious, though doable, to get it right for all platforms. Conversely, I don't know much we are going to care about speed here, but I assume that we are going to care a bit. For the linker to determine which files to pull in from an archive, it is going to have to read the symbol tables of all the input objects, and it is going to have to read the archive symbol table, and it is going to have to read the symbols table of each object included from an archive. It will have to build a symbol hash table as it goes along. This isn't fast; it's a significant component of link time. Since the compiler is also going to have to build a symbol hash table, it is going to be faster to have the compiler search the archive symbol table and decide which objects to pull in. Searching an archive symbol table isn't hard; the target dependencies come in when deciding which objects to include. In section 3.5 (Driver), although you don't discuss it, we are going to want the driver to know whether you are generating a relocateable object, a shared library, or an executable. When generating a shared library, we are going to want the driver to know the set of exported symbols. When generating an executable, we are going to want to know which symbols are referenced by shared libraries included in the link. We are going to want to know these things so that we can do things like global dead code elimination and global parameter simplification (i.e., function only called with certain parameters) even when linking against shared libraries for which we do not have the source. Link time optimization will still be useful if we don't know any of this stuff, but it is clear that people are going to want the optimizations which require it. So we should plan for it from the start. Section 4.2 (Executable Representation) describes the GVM as a stack machine, and mentions load, store, duplicate, and swap operations. But it also discusses having registers which correspond to GIMPLE local variables. The way I put this together is that a MODIFY_EXPR which sets a local variable, say, will be converted to something that computes the expression using a stack and then assigns the value to a register. It's easy to see how to convert such a MODIFY_EXPR into a stack machine and back. But it's not easy to see why that stack machine is going to need, e.g, a swap operation. There is no GIMPLE swap operator. So I may still be confused about something. Ian
