Re: deadcode optimization

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)

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