From: Andi Kleen <andi@firstfloor.org>
To: npiggin@gmail.com
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [RFC PATCH] x86: enable dead code and data elimination (LTO)
Date: Wed, 12 Jul 2017 09:29:40 -0700 [thread overview]
Message-ID: <87a849aaa3.fsf@firstfloor.org> (raw)
In-Reply-To: <20170710121329.77dd3364@roar.ozlabs.ibm.com> (Nicholas Piggin's message of "Mon, 10 Jul 2017 12:13:29 +1000")
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.
Also usually it's only useful without modules because if you
use modules EXPORT_SYMBOL pulls in a lot of unused functions.
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
-Andi
next prev parent reply other threads:[~2017-07-12 16:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-09 3:13 [RFC PATCH] x86: enable dead code and data elimination (LTO) Nicholas Piggin
2017-07-09 9:05 ` Ingo Molnar
2017-07-09 13:29 ` Masahiro Yamada
2017-07-09 13:59 ` Nicolas Pitre
2017-07-10 2:13 ` Nicholas Piggin
2017-07-12 16:29 ` Andi Kleen [this message]
2017-07-12 17:34 ` Nicolas Pitre
2017-07-13 2:51 ` Nicholas Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a849aaa3.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox