Date: Wed, 18 Sep 2013 09:44:26 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ed Schouten <ed@80386.nl>, FreeBSD Current <freebsd-current@FreeBSD.org>, Matthew Fleming <mdf@FreeBSD.org> Subject: Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections Message-ID: <9B694D6C-C679-474C-B114-D7DB5C7D9683@FreeBSD.org> In-Reply-To: <20130918062241.GW41229@kib.kiev.ua> References: <CAJOYFBBGY0GosPwG1B=1MKyapChEtX-O97r2zhXpGS8o7WO3gA@mail.gmail.com> <CAMBSHm_Qk13P=j1VOzuibYaeHFVF%2BCuXbTYL=q8ToDP6wL5X5w@mail.gmail.com> <CAJOYFBBUT5v1E6L0JkdrAXFmJmR0W2tmyNrC71k8mahLiF5vWg@mail.gmail.com> <20130918062241.GW41229@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Sep 2013, at 07:22, Konstantin Belousov <kostikbel@gmail.com> = 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B694D6C-C679-474C-B114-D7DB5C7D9683>