This is the mail archive of the
mailing list for the GCC project.
Re: Link-time optimzation
- From: Ulrich Weigand <uweigand at de dot ibm dot com>
- To: ian at airs dot com (Ian Lance Taylor)
- Cc: gcc at gcc dot gnu dot org (gcc mailing list)
- Date: Thu, 17 Nov 2005 14:07:18 +0100 (CET)
- Subject: Re: Link-time optimzation
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?
Dr. Ulrich Weigand
Linux on zSeries Development