Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1686202

Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)

From Nicholas Piggin <npiggin@gmail.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
Date 2017-07-13 05:00 +0200
Message-ID <u2Cw9-8eu-9@gated-at.bofh.it> (permalink)
References (1 earlier) <u1go1-5LI-23@gated-at.bofh.it> <u1krE-8fC-9@gated-at.bofh.it> <u1l4n-fA-13@gated-at.bofh.it> <u1wsN-7rZ-1@gated-at.bofh.it> <u2sGt-25N-15@gated-at.bofh.it>
Organization IBM

Show all headers | View raw


On Wed, 12 Jul 2017 09:29:40 -0700
Andi Kleen <andi@firstfloor.org> wrote:

> Nicholas Piggin <npiggin@gmail.com> 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
> sections.
> 
> 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
mentioned).

> 
> 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
> ported.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=lto-411-2

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!

Thanks,
Nick

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC PATCH] x86: enable dead code and data elimination (LTO) Nicholas Piggin <npiggin@gmail.com> - 2017-07-09 05:20 +0200
  Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Ingo Molnar <mingo@kernel.org> - 2017-07-09 11:10 +0200
    Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-07-09 15:30 +0200
      Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-07-09 16:10 +0200
        Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Nicholas Piggin <npiggin@gmail.com> - 2017-07-10 04:20 +0200
          Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Andi Kleen <andi@firstfloor.org> - 2017-07-12 18:30 +0200
            Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Nicolas Pitre <nico@fluxnic.net> - 2017-07-12 19:50 +0200
            Re: [RFC PATCH] x86: enable dead code and data elimination (LTO) Nicholas Piggin <npiggin@gmail.com> - 2017-07-13 05:00 +0200

csiph-web