Re: deadcode optimization

"Norman Black" <>
4 Mar 2001 01:39:49 -0500

          From comp.compilers

Related articles
deadcode optimization (Elie Khoury) (2001-03-01)
Re: deadcode optimization (2001-03-01)
Re: deadcode optimization (Hans-Bernhard Broeker) (2001-03-01)
Re: deadcode optimization (Bjorn De Sutter) (2001-03-01)
Re: deadcode optimization (Laurent Guerby) (2001-03-01)
Re: deadcode optimization (Norman Black) (2001-03-04)
Re: deadcode optimization (2001-03-08)
Re: deadcode optimization (2001-03-08)
Re: deadcode optimization (2001-03-08)
Re: deadcode optimization (Norman Black) (2001-03-10)
Re: deadcode optimization (Norman Black) (2001-03-10)
Re: deadcode optimization (2001-03-10)
[7 later articles]
| List of all articles for this month |

From: "Norman Black" <>
Newsgroups: comp.compilers
Date: 4 Mar 2001 01:39:49 -0500
Organization: Stony Brook Software
References: 01-03-012 01-03-022
Keywords: linker, optimize
Posted-Date: 04 Mar 2001 01:39:49 EST

"Smart linking" is trivial for a compiler do handle and have ALL
linkers in existence support the unused code "removal".

All that need be done is have the compiler output library/archive
files directly with one procedure per object in the library. Our
compilers have done this since 1987 and any linker appropriately does
not link in unused code.

The compiler outputs one procedure per object in the library/archive
file. If a procedure has nested procedures the nested procedures are
in the object with the "global" procedure. One object in the library
has all global variables defined in the compilation unit. The compiler
has an option to select outputting and object or library file.

I know Microsoft added objects file extensions, COMDAT, and therefore
needed linker support to smart link. Others have used extensions to do
this. I have never understood why.

Norman Black
Stony Brook Software
the reply, fubar => ix.netcom

> > Is there a way to improve "deadcode removal" = the way the linker
> > removes unreferenced functions, in order to have smaller executables ?
> As a rule of thumb, whatever you point at, there's _always_ a way to
> improve it. The key questions are different ones, thus: is it worth
> it, and if so, why isn't everybody doing it already?
> Regarding linkers, quite a lot of them cannot remove unreferenced
> function out of object modules, partly because there is no discernible
> thing as an individual function, in their input object files, or if
> there is, the cross-referencing information may not all be visible to
> the linker. The only real way around that limitation, then, is to
> stick to a one-function-per-objectfile style, as usually found in
> library implementations. ...

Post a followup to this message

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