Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
From: Nicholas Piggin
Date: Wed Jul 12 2017 - 22:52:36 EST
On Wed, 12 Jul 2017 09:29:40 -0700
Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> Nicholas Piggin <npiggin@xxxxxxxxx> writes:
> >> I think we should aim for gc-sections to be used by default and have LTO
> >> as a possible option only.
> > I agree after it starts getting implemented and debugged by small
> > system users, we could make it default in the interest of sharing
> > testing and reducing combinations.
> From what i understand the main drawback in the past was
> is that various linker versions become very slow with thousands of
> So it may cost you built time. For a special small build it's probably
> ok, but you wouldn't want to make it default.
For --gc-sections, I have found it costs almost nothing (full LTO
is a different story).
We will have to do more testing and get numbers before it's made
default of course.
> Also usually it's only useful without modules because if you
> use modules EXPORT_SYMBOL pulls in a lot of unused functions.
Yes that and several other things that cause references from live
code/data does reduce effectiveness. Nicolas has been working on
several improvements to these (including EXPORT trimming he
> BTW I'm still maintaining a "real LTO" patchkit here, which
> has some users (mainly for binary size), but also gives some
> performance. Should probably resubmit it again. The main
> issue was that the old single link patch is still not forward
Yeah we should start looking at full LTO again after --gc-sections.
I've been looking at your patches but actually before I saw your
single link patch I did another approach. Never quite got it working
exactly right, but it would be nice to avoid linking 3 extra times
every build regardless of LTO!