Re: Dead code elimination

eggert@twinsun.com (Paul Eggert)
Wed, 6 Nov 1991 04:40:34 GMT

          From comp.compilers

Related articles
Dead code elimination whatis@ucsd.edu (Steve Boswell) (1991-10-26)
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)
Re: Dead code elimination eggert@twinsun.com (1991-11-06)
Re: Dead Code Elimination preston@dawn.cs.rice.edu (1991-11-07)
dead code elimination preston@dawn.cs.rice.edu (1991-11-26)
dead code elimination preston@tera.com (1995-03-23)
| List of all articles for this month |
Newsgroups: comp.compilers
From: eggert@twinsun.com (Paul Eggert)
Keywords: C, linker
Organization: Twin Sun, Inc
References: 91-10-106 91-11-007
Date: Wed, 6 Nov 1991 04:40:34 GMT

clyde@hitech.com.au (Clyde Smith-Stubbs) writes:
>I'd still like to know why a simple printf("Hello world\n"); when compiled
>with cc -n on my Sun produces a 94K program!


But it's only 86K stripped (:-). Aside from alignment and header overhead,
the easiest way to answer your question is to type `nm -s a.out'. You'll
get some interesting results, e.g. 37K devoted to powers of two and ten.
Most of the overhead is floating point conversion routines, which typically
can be accurate, fast, or small, or any two out the three, but not all three
simultaneously. If you look carefully, you'll find other minor
inefficiencies, but the main culprit is floating point.


To put some perspective on this, I'd guess 86K of main memory now costs less
than what 86 bytes cost back when Unix was designed (in constant dollars).
--


Post a followup to this message

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