From owner-freebsd-current@FreeBSD.ORG Wed Sep 18 08:44:38 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F3D64F13; Wed, 18 Sep 2013 08:44:37 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C16F0295E; Wed, 18 Sep 2013 08:44:37 +0000 (UTC) Received: from [192.168.0.2] (cpc27-cmbg15-2-0-cust235.5-4.cable.virginmedia.com [86.27.188.236]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r8I8iVac074872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Sep 2013 08:44:33 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections From: David Chisnall In-Reply-To: <20130918062241.GW41229@kib.kiev.ua> Date: Wed, 18 Sep 2013 09:44:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B694D6C-C679-474C-B114-D7DB5C7D9683@FreeBSD.org> References: <20130918062241.GW41229@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) Cc: Ed Schouten , FreeBSD Current , Matthew Fleming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 08:44:38 -0000 On 18 Sep 2013, at 07:22, Konstantin Belousov = wrote: > I think this is a wrong direction. First, the split should be done at > the source level, as it was usually done forever. Until we are all using toolchains that support LTO (which requires = importing a new linker and will make people who complain about = buildworld memory usage even more unhappy), this approach will typically = result in worse code being generated, as the compiler has significantly = reduced scope for interprocedural analysis. > One of the offender > there was you, AFAIR. This is irrelevant to the discussion. > Second, I would rather see init and devd, and in fact all other = statically > linked binaries from our base system, to become dynamically linked. = At > least I added a knob for building toolchain dynamic, but avoided the > fight of making this default. In my (very informal) testing, a dynamically linked clang showed about a = 5% slowdown over a statically linked one. Spending some time profiling = rtld may let us improve this, but I suspect that people would complain = if compilation suddenly got slower[1], especially if the only win is a = small reduction in disk usage (which is most important on the kinds of = platforms where you're not likely to be doing a lot of compilation). David [1] Note that once we have a linker that does LTO, these numbers may = change, as we'd end up sharing the LLVM optimisation libraries between = clang and the linker so the increased code sharing might offset the = extra cost of the extra relocations.=