All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	PCI <linux-pci@vger.kernel.org>, Jian Cai <jiancai@google.com>,
	Kristof Beyls <Kristof.Beyls@arm.com>
Subject: Re: [PATCH v8 00/16] Add support for Clang LTO
Date: Fri, 4 Dec 2020 09:35:36 +0000	[thread overview]
Message-ID: <20201204093535.GB461@willie-the-truck> (raw)
In-Reply-To: <CAKwvOdnvq=L=gQMv9MHaStmKMOuD5jvffzMedhp3gytYB6R7TQ@mail.gmail.com>

On Thu, Dec 03, 2020 at 02:32:13PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 10:23 AM Will Deacon <will@kernel.org> wrote:
> > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
> > > enabled: the external GNU assembler for stand-alone assembly, and
> > > LLVM's integrated assembler for inline assembly. as-instr tests the
> > > external assembler and makes an admittedly reasonable assumption that
> > > the test is also valid for inline assembly.
> > >
> > > I agree that it would reduce confusion in future if we just always
> > > enabled IAS with LTO. Nick, Nathan, any thoughts about this?
> >
> > That works for me, although I'm happy with anything which means that the
> > assembler checks via as-instr apply to the assembler which will ultimately
> > be used.
> 
> I agree with Will.

[...]

> So I'd recommend to Sami to simply make the Kconfig also depend on
> clang's integrated assembler (not just llvm-nm and llvm-ar).  If
> someone cares about LTO with Clang as the compiler but GAS as the
> assembler, then we can revisit supporting that combination (and the
> changes to KCONFIG), but it shouldn't be something we consider Tier 1
> supported or a combination that need be supported in a minimum viable
> product. And at that point we should make it avoid clang's integrated
> assembler entirely (I suspect LTO won't work at all in that case, so
> maybe even considering it is a waste of time).
> 
> One question I have to Will; if for aarch64 LTO will depend on RCpc,
> but RCpc is an ARMv8.3 extension, what are the implications for LTO on
> pre-ARMv8.3 aarch64 processors?

It doesn't depend on RCpc -- we just emit a more expensive instruction
(an RCsc acquire) if the RCpc one is not supported by both the toolchain
and the CPU. So the implication for those processors is that READ_ONCE()
may be more expensive.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	PCI <linux-pci@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Jian Cai <jiancai@google.com>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Kristof Beyls <Kristof.Beyls@arm.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 00/16] Add support for Clang LTO
Date: Fri, 4 Dec 2020 09:35:36 +0000	[thread overview]
Message-ID: <20201204093535.GB461@willie-the-truck> (raw)
In-Reply-To: <CAKwvOdnvq=L=gQMv9MHaStmKMOuD5jvffzMedhp3gytYB6R7TQ@mail.gmail.com>

On Thu, Dec 03, 2020 at 02:32:13PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 10:23 AM Will Deacon <will@kernel.org> wrote:
> > On Thu, Dec 03, 2020 at 09:07:30AM -0800, Sami Tolvanen wrote:
> > > Without LLVM_IAS=1, Clang uses two different assemblers when LTO is
> > > enabled: the external GNU assembler for stand-alone assembly, and
> > > LLVM's integrated assembler for inline assembly. as-instr tests the
> > > external assembler and makes an admittedly reasonable assumption that
> > > the test is also valid for inline assembly.
> > >
> > > I agree that it would reduce confusion in future if we just always
> > > enabled IAS with LTO. Nick, Nathan, any thoughts about this?
> >
> > That works for me, although I'm happy with anything which means that the
> > assembler checks via as-instr apply to the assembler which will ultimately
> > be used.
> 
> I agree with Will.

[...]

> So I'd recommend to Sami to simply make the Kconfig also depend on
> clang's integrated assembler (not just llvm-nm and llvm-ar).  If
> someone cares about LTO with Clang as the compiler but GAS as the
> assembler, then we can revisit supporting that combination (and the
> changes to KCONFIG), but it shouldn't be something we consider Tier 1
> supported or a combination that need be supported in a minimum viable
> product. And at that point we should make it avoid clang's integrated
> assembler entirely (I suspect LTO won't work at all in that case, so
> maybe even considering it is a waste of time).
> 
> One question I have to Will; if for aarch64 LTO will depend on RCpc,
> but RCpc is an ARMv8.3 extension, what are the implications for LTO on
> pre-ARMv8.3 aarch64 processors?

It doesn't depend on RCpc -- we just emit a more expensive instruction
(an RCsc acquire) if the RCpc one is not supported by both the toolchain
and the CPU. So the implication for those processors is that READ_ONCE()
may be more expensive.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-12-04  9:36 UTC|newest]

Thread overview: 141+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 21:36 [PATCH v8 00/16] Add support for Clang LTO Sami Tolvanen
2020-12-01 21:36 ` Sami Tolvanen
2020-12-01 21:36 ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 01/16] tracing: move function tracer options to Kconfig Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:47   ` Steven Rostedt
2020-12-01 21:47     ` Steven Rostedt
2020-12-01 21:36 ` [PATCH v8 02/16] kbuild: add support for Clang LTO Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-02  2:59   ` Masahiro Yamada
2020-12-02  2:59     ` Masahiro Yamada
2020-12-03  0:07   ` Nick Desaulniers
2020-12-03  0:07     ` Nick Desaulniers
2020-12-03  0:07     ` Nick Desaulniers
2020-12-01 21:36 ` [PATCH v8 03/16] kbuild: lto: fix module versioning Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 04/16] kbuild: lto: limit inlining Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 05/16] kbuild: lto: merge module sections Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 06/16] kbuild: lto: remove duplicate dependencies from .mod files Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 07/16] init: lto: ensure initcall ordering Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36 ` [PATCH v8 08/16] init: lto: fix PREL32 relocations Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:36   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 09/16] PCI: Fix PREL32 relocations for LTO Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 10/16] modpost: lto: strip .lto from module names Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 11/16] scripts/mod: disable LTO for empty.c Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 12/16] efi/libstub: disable LTO Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 13/16] drivers/misc/lkdtm: disable LTO for rodata.o Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 14/16] arm64: vdso: disable LTO Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 15/16] arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37 ` [PATCH v8 16/16] arm64: allow LTO to be selected Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-01 21:37   ` Sami Tolvanen
2020-12-03  0:01 ` [PATCH v8 00/16] Add support for Clang LTO Nick Desaulniers
2020-12-03  0:01   ` Nick Desaulniers
2020-12-03  0:01   ` Nick Desaulniers
2020-12-03 11:26 ` Will Deacon
2020-12-03 11:26   ` Will Deacon
2020-12-03 17:07   ` Sami Tolvanen
2020-12-03 17:07     ` Sami Tolvanen
2020-12-03 17:07     ` Sami Tolvanen
2020-12-03 18:21     ` Nathan Chancellor
2020-12-03 18:21       ` Nathan Chancellor
2020-12-03 18:22     ` Will Deacon
2020-12-03 18:22       ` Will Deacon
2020-12-03 22:32       ` Nick Desaulniers
2020-12-03 22:32         ` Nick Desaulniers
2020-12-03 22:32         ` Nick Desaulniers
2020-12-04  9:35         ` Will Deacon [this message]
2020-12-04  9:35           ` Will Deacon
2020-12-04 22:52         ` Sami Tolvanen
2020-12-04 22:52           ` Sami Tolvanen
2020-12-04 22:52           ` Sami Tolvanen
2020-12-06  6:50           ` Nathan Chancellor
2020-12-06  6:50             ` Nathan Chancellor
2020-12-06 20:09             ` Sami Tolvanen
2020-12-06 20:09               ` Sami Tolvanen
2020-12-06 20:09               ` Sami Tolvanen
2020-12-08  0:46               ` Nathan Chancellor
2020-12-08  0:46                 ` Nathan Chancellor
2020-12-08 12:15 ` Arnd Bergmann
2020-12-08 12:15   ` Arnd Bergmann
2020-12-08 12:15   ` Arnd Bergmann
2020-12-08 13:54   ` Arnd Bergmann
2020-12-08 13:54     ` Arnd Bergmann
2020-12-08 13:54     ` Arnd Bergmann
2020-12-08 16:53     ` Sami Tolvanen
2020-12-08 16:53       ` Sami Tolvanen
2020-12-08 16:53       ` Sami Tolvanen
2020-12-08 16:56       ` Arnd Bergmann
2020-12-08 16:56         ` Arnd Bergmann
2020-12-08 16:56         ` Arnd Bergmann
2020-12-08 16:43   ` Sami Tolvanen
2020-12-08 16:43     ` Sami Tolvanen
2020-12-08 16:43     ` Sami Tolvanen
2020-12-08 20:59     ` Arnd Bergmann
2020-12-08 20:59       ` Arnd Bergmann
2020-12-08 21:02       ` Arnd Bergmann
2020-12-08 21:02         ` Arnd Bergmann
2020-12-09  5:23         ` Fāng-ruì Sòng
2020-12-09  5:23           ` Fāng-ruì Sòng
2020-12-09  5:23           ` Fāng-ruì Sòng
2020-12-09  9:07           ` Arnd Bergmann
2020-12-09  9:07             ` Arnd Bergmann
2020-12-09  9:07             ` Arnd Bergmann
2020-12-09  9:59         ` Arnd Bergmann
2020-12-09  9:59           ` Arnd Bergmann
2020-12-09 16:09         ` Sami Tolvanen
2020-12-09 16:09           ` Sami Tolvanen
2020-12-09 16:09           ` Sami Tolvanen
2020-12-09 19:24           ` Arnd Bergmann
2020-12-09 19:24             ` Arnd Bergmann
2020-12-09 19:24             ` Arnd Bergmann
2020-12-08 21:09       ` Nick Desaulniers
2020-12-08 21:09         ` Nick Desaulniers
2020-12-08 21:09         ` Nick Desaulniers
2020-12-08 22:20         ` Arnd Bergmann
2020-12-08 22:20           ` Arnd Bergmann
2020-12-08 22:20           ` Arnd Bergmann
2020-12-09 16:11           ` Sami Tolvanen
2020-12-09 16:11             ` Sami Tolvanen
2020-12-09 16:11             ` Sami Tolvanen
2020-12-09  4:55     ` Fangrui Song
2020-12-09  4:55       ` Fangrui Song
2020-12-09  9:19       ` Arnd Bergmann
2020-12-09  9:19         ` Arnd Bergmann
2020-12-09  9:19         ` Arnd Bergmann
2020-12-09 12:35   ` Arnd Bergmann
2020-12-09 12:35     ` Arnd Bergmann
2020-12-09 12:35     ` Arnd Bergmann
2020-12-09 16:25     ` Sami Tolvanen
2020-12-09 16:25       ` Sami Tolvanen
2020-12-09 16:25       ` Sami Tolvanen
2020-12-09 17:51       ` Arnd Bergmann
2020-12-09 17:51         ` Arnd Bergmann
2020-12-09 17:51         ` 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=20201204093535.GB461@willie-the-truck \
    --to=will@kernel.org \
    --cc=Kristof.Beyls@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiancai@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=samitolvanen@google.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 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.