Re: Link-time optimzation

[Ulrich Weigand <uweigand at de dot ibm dot com>]

Ian Lance Taylor wrote:

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

I'm wondering whether we can't simply employ the linker to handle
all those issues:  Have the driver always (not just as fall-back)
call "ld -r" and the linker will pull together all input files,
including those from archives, and combine them into one single
object file.  Then invoke the new "link-optimizer" on that single
object file, resulting in an optimized object file.

Any reasons why this cannot work?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com