Re: -ffunction-sections, -fdata-sections and -Wl,--gc-sections

On 18 Sep 2013, at 07:22, Konstantin Belousov <kostikbel_at_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.