From owner-freebsd-chat Mon Sep 14 07:30:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA11385 for freebsd-chat-outgoing; Mon, 14 Sep 1998 07:30:28 -0700 (PDT) (envelope-from owner-freebsd-chat@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA11201 for ; Mon, 14 Sep 1998 07:30:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id QAA25086; Mon, 14 Sep 1998 16:15:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA19415; Mon, 14 Sep 1998 16:15:30 +0200 (MET DST) Message-ID: <19980914161530.26760@follo.net> Date: Mon, 14 Sep 1998 16:15:30 +0200 From: Eivind Eklund To: Mike Smith Cc: freebsd-chat@FreeBSD.ORG Subject: Re: Unused functions References: <199809140009.TAA28013@isua4.iastate.edu> <199809140114.SAA08497@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199809140114.SAA08497@word.smith.net.au>; from Mike Smith on Sun, Sep 13, 1998 at 06:14:32PM -0700 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 13, 1998 at 06:14:32PM -0700, Mike Smith wrote: > > Just so I completely understand, if I truely use only one function in from > > a .o file and no other function is using anything in this .o file, the > > entire .o file is still pulled into the executable? So, there are could be > > a lot of unused, unreachable code in an executable. Nothing can be done to > > remove the bloat after the executable has been linked? Is this commonly the > > way its done on other systems as well? I had always assumed that unused > > functions and data were tosed out. > > In most object formats, reference information is kept on a per-object > basis (ie. per .o file). Keeping this sort of information on any > smaller granularity would lead to an insane increase in the complexity > and corresponding performance reduction of the link phase. "Insane" is somewhat an overstatement here. E.g. Eiffel and Sather does things this way, doing a full call-tree analysis to throw away unused code (globally). This does not spend large amounts of time. If I have to choose between the compiler/linker spending a little more time and generating incorrect or sub-optimal code, I will almost always want the linker & compiler to spend more time. Eivind, who want link-time optimization - to get truly global optimizations. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message