Re: deadcode optimization

> 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
> (www.freepascal.org)


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

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