Re: Link-time optimzation

[Ian Lance Taylor <ian@airs.com>]

Mark Mitchell <mark@codesourcery.com> 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