From: David Laight <david.laight.linux@gmail.com>
To: Marco Elver <elver@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will@kernel.org>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Boqun Feng <boqun.feng@gmail.com>,
Waiman Long <longman@redhat.com>,
Bart Van Assche <bvanassche@acm.org>,
llvm@lists.linux.dev, Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] arm64: Optimize __READ_ONCE() with CONFIG_LTO=y
Date: Tue, 27 Jan 2026 14:30:26 +0000 [thread overview]
Message-ID: <20260127143026.32429f32@pumpkin> (raw)
In-Reply-To: <CANpmjNNWoSdE_Lo9CJV3sAR+j8qz3_sq7LoaqYO6cVuOtdTBzA@mail.gmail.com>
On Tue, 27 Jan 2026 13:01:22 +0100
Marco Elver <elver@google.com> wrote:
> On Mon, 26 Jan 2026 at 23:24, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Jan 26, 2026, at 20:54, Marco Elver wrote:
> > > On Mon, Jan 26, 2026 at 08:56AM +0100, Arnd Bergmann wrote:
> > >> On Mon, Jan 26, 2026, at 01:25, Marco Elver wrote:
> > >>
> > >> How does this work with CC_HAS_TYPEOF_UNQUAL=false?
> > >>
> > >> As far as I can tell, TYPEOF_UNQUAL() falls back to __typeof__
> > >> on gcc-13, clang-18 and earlier, and not strip out qualifiers.
> > >
> > > I think we only need to worry about Clang for LTO builds. But yeah, our
> > > minimum supported Clang is 15, so between 15-18 it'd be broken.
> >
> > Right, I missed the #ifdef CONFIG_LTO check, so indeed gcc is
> > fine here.
> >
> > >> With fd69b2f7d5f4 ("compiler: Use __typeof_unqual__() for
> > >> __unqual_scalar_typeof()"), I would expect __unqual_scalar_typeof()
> > >> to do the right thing already.
> > >
> > > It'd still be broken for Clang 15-18, so it won't help much. We need
> > > this to work for more than "scalar", so even though it'll work for Clang
> > > 19+ given the redefinition to __typeof_unqual__, we should deprecate the
> > > _Generic-based __unqual_scalar_typeof() sooner than later.
> > >
> > > I was able to make this work for older compilers:
> > >
> > ...
> > > #define __READ_ONCE(x) \
> > > ({ \
> > > auto __x = &(x); \
> > > - auto __ret = (TYPEOF_UNQUAL(*__x) *)__x, *__retp = &__ret; \
> > > - union { TYPEOF_UNQUAL(*__x) __val; char __c[1]; } __u; \
> > > + auto __ret = (__read_once_typeof(*__x) *)__x, *__retp = &__ret; \
> > > + union { __read_once_typeof(*__x) __val; char __c[1]; } __u; \
> > > *__retp = &__u.__val; \
> >
> > >
> > > Thoughts?
> >
> > Looks better than __unqual_scalar_typeof() to me. Would it make
> > sense to do the same __read_once_typeof() in the asm-generic
> > version of __READ_ONCE()? I don't remember if we discussed it
> > in the thread leading up to dee081bf8f82 ("READ_ONCE: Drop
> > pointer qualifiers when reading from scalar types").
> > We probably didn't have __auto_type back then.
>
> I don't see the point for the asm-generic __READ_ONCE(): it's not
> wrong to cast to 'const volatile volatile T*' nor 'const volatile
> const T*' etc., which is dereferenced directly and not stored in any
> temporary variable when used in READ_ONCE(). I actually don't know why
> __unqual_scalar_typeof() is used in the asm-generic __READ_ONCE(),
> which just adds 'const volatile' right back.
That looks historic, once upon a time the code was:
typeof(x) __x = __READ_ONCE(x);
smp_read_barrier_depends();
__x;
but const needed stripping and someone decided to cast the result back
to the original type.
Of course that is pointless since the qualifiers aren't relevant on an
'rvalue' so are then discarded.
Then the barrier and temporary variable got removed.
(The barrier was only needed for alpha - which has its own __READ_ONCE()).
In the arm LTO version the ?: will also remove the qualifiers.
>
> And __READ_ONCE_SCALAR() appears to be gone, where the
> qualifier-stripping resulted in better code-gen.
The qualifier stripping was needed to read a 'const' variable.
Looks to me like the 'better code gen' happened earlier.
The 'earlier' version took the address of the on-stack volatile
variable.
So you may not need to remove the const/volatile qualifiers at all.
David
next prev parent reply other threads:[~2026-01-27 14:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 0:25 [PATCH 0/3] arm64: Fixes for __READ_ONCE() with CONFIG_LTO=y Marco Elver
2026-01-26 0:25 ` [PATCH 1/3] arm64: Fix non-atomic " Marco Elver
2026-01-26 0:25 ` [PATCH 2/3] arm64: Optimize " Marco Elver
2026-01-26 7:56 ` Arnd Bergmann
2026-01-26 19:54 ` Marco Elver
2026-01-26 22:24 ` Arnd Bergmann
2026-01-27 12:01 ` Marco Elver
2026-01-27 14:30 ` David Laight [this message]
2026-01-27 15:04 ` Marco Elver
2026-01-27 18:54 ` David Laight
2026-01-26 22:55 ` David Laight
2026-01-26 11:16 ` David Laight
2026-01-26 23:15 ` Marco Elver
2026-01-27 10:13 ` David Laight
2026-01-26 0:25 ` [PATCH 3/3] arm64, compiler-context-analysis: Permit alias analysis through " Marco Elver
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=20260127143026.32429f32@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=catalin.marinas@arm.com \
--cc=elver@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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: 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