Re: deadcode optimization

fjh@cs.mu.OZ.AU (Fergus Henderson)
8 Mar 2001 12:27:43 -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)
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-03-10)
Re: deadcode optimization stonybrk@ix.netcom.com (Norman Black) (2001-03-10)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-10)
Re: deadcode optimization fjh@cs.mu.OZ.AU (2001-03-12)
[6 later articles]
| List of all articles for this month |

From: fjh@cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.compilers
Date: 8 Mar 2001 12:27:43 -0500
Organization: Computer Science, University of Melbourne
References: 01-03-012 01-03-022 01-03-034
Keywords: linker, optimize
Posted-Date: 08 Mar 2001 12:27:43 EST

"Norman Black" <stonybrk@fubar.com> writes:


>"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.
[...]
>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.


I think the main reason is that typical object file formats and
library formats have a lot of overhead per object file. Compiling
each function to its own object file results in much larger object and
library files, and as a result can also increase compilation and link
times. I implemented the same kind of thing in the Mercury compiler
in 1996, but it remains an option, not the default, because of the
large increase in the intermediate file sizes and in compilation /
link time. It's useful if you're cross-compiling to some small-memory
system, or if for some other reason you're very concerned about
reducing code size, but otherwise it's not worth the hassle.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.


Post a followup to this message

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