Dead code elimination

Steve Boswell <whatis@ucsd.edu>
26 Oct 91 18:06:43 GMT

          From comp.compilers

Related articles
Dead code elimination whatis@ucsd.edu (Steve Boswell) (1991-10-26)
re: Dead code elimination chuck_lins1@gateway.qm.apple.com (Chuck Lins) (1991-10-28)
Re: Dead code elimination henry@zoo.toronto.edu (1991-10-29)
Re: Dead code elimination clyde@hitech.com.au (1991-11-01)
Re: Dead code elimination henry@zoo.toronto.edu (1991-11-05)
Re: Dead code elimination schwartz@roke.cs.psu.edu (1991-11-05)
Re: Dead code elimination dd@mips.com (1991-11-05)
[4 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: Steve Boswell <whatis@ucsd.edu>
Keywords: linker, question
Organization: University of California, San Diego
Date: 26 Oct 91 18:06:43 GMT

Under some compiler environments, calling a particular library function
causes a group of other library functions to be loaded in, which cause
more library functions to be loaded in, etc. when very few of them are
actually used. Is there anything outside of global flow analysis that
can remedy this?


On a related topic, is there any advantage to turning each .o file of
compiled functions into an equivalent library produced by ar and ranlib?


Steve Boswell
whatis@ucsd.edu
[To the first question, the basic problem is that a single module in the
library often includes several routines, some of which you want and some
of which you don't, and the ones you don't can refer to other stuff,
bloating your object files with crud. Putting each routine in a separate
module helps some, at the cost of having a zillion little source files for
the library. Even flow analysis isn't really enough, since routines like
printf are prepared to handle every possible format type even if a program
doesn't use them all, which can drag in things like large amounts of unused
floating point formatting code. In many environments, SVR4/SunOS type shared
libraries mitigate this problem considerably. To the second question, no
unless you have some extremely badly written makefiles. -John]
--


Post a followup to this message

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