Re: deadcode optimization

Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de>
1 Mar 2001 14:17:16 -0500

          From comp.compilers

Related articles
deadcode optimization khoury@club-internet.fr (Elie Khoury) (2001-03-01)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-01)
Re: deadcode optimization broeker@physik.rwth-aachen.de (Hans-Bernhard Broeker) (2001-03-01)
Re: deadcode optimization Bjorn.DeSutter@rug.ac.be (Bjorn De Sutter) (2001-03-01)
Re: deadcode optimization guerby@acm.org (Laurent Guerby) (2001-03-01)
Re: deadcode optimization stonybrk@fubar.com (Norman Black) (2001-03-04)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-08)
Re: deadcode optimization tgi@netgem.com (2001-03-08)
Re: deadcode optimization rog@vitanuova.com (2001-03-08)
[10 later articles]
| List of all articles for this month |

From: Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de>
Newsgroups: comp.compilers
Date: 1 Mar 2001 14:17:16 -0500
Organization: Aachen University of Technology (RWTH)
References: 01-03-012
Keywords: linker, optimize
Posted-Date: 01 Mar 2001 14:17:16 EST

Elie Khoury <khoury@club-internet.fr> wrote:
> 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.


Note that to a linker, an object file usually is just a big lump of
bytes organized into sections, with some particular places annotated
by labels and some others to be filled in by the linker, in ways
formally given by relocation records.


On some architectures, a compiler could, e.g., resolve calls from one
function to the other inside a given translation unit itself, without
relying on the linker, or even telling it about it. Or it may move the
only copy of one function's code inlined into the body of
another. I.e. the linker wouldn't know about all existing function
calls, and thus might think some function is not needed, when in fact
it is.


> I noticed gcc is very bad with this operation.


That's not GCC's fault, if at all: it's the linker, and GCC does not
contain one (it's in another GNU package, or provided by the OS
vendoer).


You mentioned function pointers, and that you don't use them. But
there's no direct way the linker can know that, right? So it has to
assume you may use some, and has to be prepared for it.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)


Post a followup to this message

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