From: Fangrui Song <maskray@google.com> To: Nicolas Pitre <nico@fluxnic.net> Cc: Nicholas Piggin <npiggin@gmail.com>, Arnd Bergmann <arnd@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Andrew Scull <ascull@google.com>, Mark Brown <broonie@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, clang-built-linux <clang-built-linux@googlegroups.com>, David Brazdil <dbrazdil@google.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Ionela Voinescu <ionela.voinescu@arm.com>, Kees Cook <keescook@chromium.org>, Kristina Martsenko <kristina.martsenko@arm.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, Marc Zyngier <maz@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org> Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Wed, 10 Mar 2021 14:42:09 -0800 [thread overview] Message-ID: <20210310224209.otjkhwng4hlislnj@google.com> (raw) In-Reply-To: <3o63p7pp-50o9-2789-s3qo-99pp5nrnnoqp@syhkavp.arg> On 2021-03-10, Nicolas Pitre wrote: >On Mon, 1 Mar 2021, Nicholas Piggin wrote: > >> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm: >> > Unlike what Nick expected in his submission, I now think the annotations >> > will be needed for LTO just like they are for --gc-sections. >> >> Yeah I wasn't sure exactly what LTO looks like or how it would work. >> I thought perhaps LTO might be able to find dead code with circular / >> back references, we could put references from the code back to these >> tables or something so they would be kept without KEEP. I don't know, I >> was handwaving! >> >> I managed to get powerpc (and IIRC x86?) working with gc sections with >> those KEEP annotations, but effectiveness of course is far worse than >> what Nicolas was able to achieve with all his techniques and tricks. >> >> But yes unless there is some other mechanism to handle these tables, >> then KEEP probably has to stay. I suggest this wants a very explicit and >> systematic way to handle it (maybe with some toolchain support) rather >> than trying to just remove things case by case and see what breaks. >> >> I don't know if Nicolas is still been working on his shrinking patches >> recenty but he probably knows more than anyone about this stuff. > >Looks like not much has changed since last time I played with this stuff. > >There is a way to omit the KEEP() on tables, but something must create a >dependency from the code being pointed to by those tables to the table >entries themselves. I did write my findings in the following article >(just skip over the introductory blurb): > >https://lwn.net/Articles/741494/ Hey, this article taught me R_*_NONE which motivated me to add various R_*_NONE support to LLVM 9! In the weekend I noticed that with binutils>=2.26, one can use .reloc ., BFD_RELOC_NONE, target (https://sourceware.org/bugzilla/show_bug.cgi?id=27530 ). I implemented it for many targets in LLVM, but that will require 13.0.0. >Once that dependency is there, then the KEEP() may go and >garbage-collecting a function will also garbage-collect the table entry >automatically. > >OTOH this trickery is not needed with LTO as garbage collection happens >at the source code optimization level. The KEEP() may remain in that >case as unneeded table entries will simply not be created in the first >place. For Thin LTO, --gc-sections is still very useful. I have more notes in https://maskray.me/blog/2021-02-28-linker-garbage-collection#link-time-optimization .
WARNING: multiple messages have this Message-ID (diff)
From: Fangrui Song <maskray@google.com> To: Nicolas Pitre <nico@fluxnic.net> Cc: Nicholas Piggin <npiggin@gmail.com>, Arnd Bergmann <arnd@kernel.org>, Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Andrew Scull <ascull@google.com>, Mark Brown <broonie@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, clang-built-linux <clang-built-linux@googlegroups.com>, David Brazdil <dbrazdil@google.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Ionela Voinescu <ionela.voinescu@arm.com>, Kees Cook <keescook@chromium.org>, Kristina Martsenko <kristina.martsenko@arm.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Mark Rutland <mark.rutland@arm.com>, Marc Zyngier <maz@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Vincenzo Frascino <vincenzo.frascino@arm.com>, Will Deacon <will@kernel.org> Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Date: Wed, 10 Mar 2021 14:42:09 -0800 [thread overview] Message-ID: <20210310224209.otjkhwng4hlislnj@google.com> (raw) In-Reply-To: <3o63p7pp-50o9-2789-s3qo-99pp5nrnnoqp@syhkavp.arg> On 2021-03-10, Nicolas Pitre wrote: >On Mon, 1 Mar 2021, Nicholas Piggin wrote: > >> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm: >> > Unlike what Nick expected in his submission, I now think the annotations >> > will be needed for LTO just like they are for --gc-sections. >> >> Yeah I wasn't sure exactly what LTO looks like or how it would work. >> I thought perhaps LTO might be able to find dead code with circular / >> back references, we could put references from the code back to these >> tables or something so they would be kept without KEEP. I don't know, I >> was handwaving! >> >> I managed to get powerpc (and IIRC x86?) working with gc sections with >> those KEEP annotations, but effectiveness of course is far worse than >> what Nicolas was able to achieve with all his techniques and tricks. >> >> But yes unless there is some other mechanism to handle these tables, >> then KEEP probably has to stay. I suggest this wants a very explicit and >> systematic way to handle it (maybe with some toolchain support) rather >> than trying to just remove things case by case and see what breaks. >> >> I don't know if Nicolas is still been working on his shrinking patches >> recenty but he probably knows more than anyone about this stuff. > >Looks like not much has changed since last time I played with this stuff. > >There is a way to omit the KEEP() on tables, but something must create a >dependency from the code being pointed to by those tables to the table >entries themselves. I did write my findings in the following article >(just skip over the introductory blurb): > >https://lwn.net/Articles/741494/ Hey, this article taught me R_*_NONE which motivated me to add various R_*_NONE support to LLVM 9! In the weekend I noticed that with binutils>=2.26, one can use .reloc ., BFD_RELOC_NONE, target (https://sourceware.org/bugzilla/show_bug.cgi?id=27530 ). I implemented it for many targets in LLVM, but that will require 13.0.0. >Once that dependency is there, then the KEEP() may go and >garbage-collecting a function will also garbage-collect the table entry >automatically. > >OTOH this trickery is not needed with LTO as garbage collection happens >at the source code optimization level. The KEEP() may remain in that >case as unneeded table entries will simply not be created in the first >place. For Thin LTO, --gc-sections is still very useful. I have more notes in https://maskray.me/blog/2021-02-28-linker-garbage-collection#link-time-optimization . _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-10 22:43 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-25 11:20 [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION Arnd Bergmann 2021-02-25 11:20 ` Arnd Bergmann 2021-02-25 20:16 ` Kees Cook 2021-02-25 20:16 ` Kees Cook 2021-02-26 0:36 ` Sedat Dilek 2021-02-26 0:36 ` Sedat Dilek 2021-02-26 8:14 ` Arnd Bergmann 2021-02-26 8:14 ` Arnd Bergmann 2021-02-26 9:05 ` Sedat Dilek 2021-02-26 9:05 ` Sedat Dilek 2021-02-26 9:51 ` Arnd Bergmann 2021-02-26 9:51 ` Arnd Bergmann 2021-02-26 10:02 ` Sedat Dilek 2021-02-26 10:02 ` Sedat Dilek 2021-02-27 20:13 ` Sedat Dilek 2021-02-26 21:13 ` Fangrui Song 2021-02-26 21:13 ` Fangrui Song 2021-02-27 9:49 ` Arnd Bergmann 2021-02-27 9:49 ` Arnd Bergmann 2021-03-01 1:11 ` Nicholas Piggin 2021-03-01 1:11 ` Nicholas Piggin 2021-03-10 20:49 ` Masahiro Yamada 2021-03-10 20:49 ` Masahiro Yamada 2021-03-10 21:08 ` Arnd Bergmann 2021-03-10 21:08 ` Arnd Bergmann 2021-03-10 21:24 ` Sedat Dilek 2021-03-10 21:24 ` Sedat Dilek 2021-03-10 21:47 ` Nicolas Pitre 2021-03-10 21:47 ` Nicolas Pitre 2021-03-10 21:57 ` Sedat Dilek 2021-03-10 21:57 ` Sedat Dilek 2021-03-10 22:02 ` Nick Desaulniers 2021-03-10 22:02 ` Nick Desaulniers 2021-03-10 22:08 ` Nicolas Pitre 2021-03-10 22:08 ` Nicolas Pitre 2021-03-10 22:29 ` Fangrui Song 2021-03-10 22:29 ` Fangrui Song 2021-03-10 21:45 ` Rasmus Villemoes 2021-03-10 21:45 ` Rasmus Villemoes 2021-03-10 21:19 ` Nicolas Pitre 2021-03-10 21:19 ` Nicolas Pitre 2021-03-10 22:42 ` Fangrui Song [this message] 2021-03-10 22:42 ` Fangrui Song 2021-03-17 14:37 ` Catalin Marinas 2021-03-17 14:37 ` Catalin Marinas 2021-03-17 16:18 ` Catalin Marinas 2021-03-17 16:18 ` Catalin Marinas 2021-03-18 8:41 ` Arnd Bergmann 2021-03-18 8:41 ` Arnd Bergmann 2021-03-19 12:25 ` Catalin Marinas 2021-03-19 12:25 ` Catalin Marinas 2021-03-19 14:01 ` Arnd Bergmann 2021-03-19 14:01 ` Arnd Bergmann
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=20210310224209.otjkhwng4hlislnj@google.com \ --to=maskray@google.com \ --cc=ardb@kernel.org \ --cc=arnd@arndb.de \ --cc=arnd@kernel.org \ --cc=ascull@google.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=clang-built-linux@googlegroups.com \ --cc=dbrazdil@google.com \ --cc=geert+renesas@glider.be \ --cc=ionela.voinescu@arm.com \ --cc=keescook@chromium.org \ --cc=kristina.martsenko@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=nathan@kernel.org \ --cc=ndesaulniers@google.com \ --cc=nico@fluxnic.net \ --cc=npiggin@gmail.com \ --cc=vincenzo.frascino@arm.com \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.