Re: deadcode optimization

"Norman Black" <>
10 Apr 2001 01:21:16 -0400

          From comp.compilers

Related articles
[11 earlier articles]
Re: deadcode optimization (2001-03-10)
Re: deadcode optimization (2001-03-12)
Re: deadcode optimization (Norman Black) (2001-03-14)
Re: deadcode optimization (Norman Black) (2001-03-14)
Re: deadcode optimization (Hans-Bernhard Broeker) (2001-03-22)
Re: deadcode optimization (Marco van de Voort) (2001-04-04)
Re: deadcode optimization (Norman Black) (2001-04-10)
Re: deadcode optimization (2001-04-12)
| List of all articles for this month |

From: "Norman Black" <>
Newsgroups: comp.compilers
Date: 10 Apr 2001 01:21:16 -0400
Organization: Stony Brook Software
References: 01-03-012 01-03-022 01-03-034 01-03-060 01-03-075 01-03-091 01-03-099 01-04-020
Keywords: optimize, linker
Posted-Date: 10 Apr 2001 01:21:16 EDT

> For deadcode removal, the linker is indeed the problem. One can solve this
> by creating an object file per symbol. This is horribly slow.

Maybe for some linkers. Certainly not our linker, or some of the old
superfast DOS linkers like optlink and blink. Turbo Pascal was
extremely fast, but they used a proprietary format (TPU) which may, or
may not, have helped in this regard.

Linking archives is slower than straight objects. For "Unix" systems
the Unix archive format certainly does not help as it is something of
a joke with regards to the archive symbol table. In the Win32 world
Microsoft solved this with an extended archive symbol table format,
which we use. Our compiler and librarian program (like ar) can output
these extended archives on COFF and ELF archives. Our linker can still
deal with the absence of the extended archive symbol table, but that
adds an amount of compute time to sort the standard Unix archive
symbol table for fast searches. Just why it was not mandated that the
archive symbol table be sorted by symbol name is beyond me. Yes, the
linker can do this, but the archive is created once, and a linker uses
the archive multiple times. Doing something once is always better.

The DOS library (archive) format never had this problem since the
library symbol table was actually a hash table.

>The slowlyness can be reduced a magnitude of 2 by elimintating the backend
> assembler and directly pooping out .a's with all objects
> If you want an example for this, check the Free Pascal compiler
> (

Our compiler(s) go from source file input to object file output with
nothing in between but data in memory.
Norman Black
Stony Brook Software

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.