[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNP8xwyjiDRgzWO13K3rPbxM0gRwTvMvX3Amm-QOWD0_tQ@mail.gmail.com>
Date: Wed, 8 Jul 2020 09:15:44 +0200
From: Marco Elver <elver@...gle.com>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Dave Martin <Dave.Martin@....com>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Mark Rutland <mark.rutland@....com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Catalin Marinas <catalin.marinas@....com>,
Jason Wang <jasowang@...hat.com>,
virtualization@...ts.linux-foundation.org,
Alan Stern <stern@...land.harvard.edu>,
Matt Turner <mattst88@...il.com>,
kernel-team <kernel-team@...roid.com>,
Kees Cook <keescook@...omium.org>,
Arnd Bergmann <arnd@...db.de>,
Boqun Feng <boqun.feng@...il.com>,
Josh Triplett <josh@...htriplett.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Richard Henderson <rth@...ddle.net>,
LKML <linux-kernel@...r.kernel.org>, linux-alpha@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y
On Wed, 8 Jul 2020 at 01:01, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> I'm trying to put together a Micro Conference for Linux Plumbers
> conference focused on "make LLVM slightly less shitty." Do you all
> plan on attending the conference? Would it be worthwhile to hold a
> session focused on discussing this (LTO and memory models) be
> worthwhile?
I would welcome sessions on LLVM, and would try to attend. Apart from
general improvements to the LLVM ecosystem, we should also emphasize
the benefits LLVM provides and how we can enable them (one reason we
want LTO is to get CFI).
Regarding LTO and memory models, I'm not sure. Given the current state
of things, such a discussion needs to be carefully framed to not go in
circles, because we're trying to figure out things at the intersection
of architecture, what the compiler does, the C standard, and the
kernel wants. And because some of these boxes are difficult to change
(standard, arch, compiler) or difficult to precisely define behaviour
(compiler), we might end up going in circles. From what I see there
are efforts to fix the situation at the root (standard), and we might
have means to get the compiler to tell us what it's doing. But these
happen extremely slowly.
So, if we do this, we need to be careful to not end up re-discussing
what we discussed here, but rather try and make it a continuation that
hopefully leads to some constructive output.
Thanks,
-- Marco
Powered by blists - more mailing lists