|
Message-ID: <20200624211540.GS4817@hirez.programming.kicks-ass.net> Date: Wed, 24 Jun 2020 23:15:40 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Sami Tolvanen <samitolvanen@...gle.com> Cc: Masahiro Yamada <masahiroy@...nel.org>, Will Deacon <will@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Paul E. McKenney" <paulmck@...nel.org>, Kees Cook <keescook@...omium.org>, Nick Desaulniers <ndesaulniers@...gle.com>, clang-built-linux@...glegroups.com, kernel-hardening@...ts.openwall.com, linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org, x86@...nel.org Subject: Re: [PATCH 00/22] add support for Clang LTO On Wed, Jun 24, 2020 at 01:31:38PM -0700, Sami Tolvanen wrote: > This patch series adds support for building x86_64 and arm64 kernels > with Clang's Link Time Optimization (LTO). > > In addition to performance, the primary motivation for LTO is to allow > Clang's Control-Flow Integrity (CFI) to be used in the kernel. Google's > Pixel devices have shipped with LTO+CFI kernels since 2018. > > Most of the patches are build system changes for handling LLVM bitcode, > which Clang produces with LTO instead of ELF object files, postponing > ELF processing until a later stage, and ensuring initcall ordering. > > Note that first objtool patch in the series is already in linux-next, > but as it's needed with LTO, I'm including it also here to make testing > easier. I'm very sad that yet again, memory ordering isn't addressed. LTO vastly increases the range of the optimizer to wreck things.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.