Re: Link-time optimzation

[Ian Lance Taylor <ian at airs dot com>]

Ulrich Weigand <uweigand@de.ibm.com> writes:

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

Well, it means having the linker do a fair amount of work and then
throwing it all away.  And there might be some effort involved in
teasing out the debug information again, although I'm sure that could
be handled.  I tend to think the extra disk I/O and computation would
make this idea a non-starter, but I could certainly be wrong.  It does
seem like a viable fallback position.

Ian