public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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 18:54:24 +0000	[thread overview]
Message-ID: <20260127185424.39d801ea@pumpkin> (raw)
In-Reply-To: <CANpmjNP6qRm0M9Za-=Lm8N87o-GukO5nQeAVpW=bbXRnip4Fvg@mail.gmail.com>

On Tue, 27 Jan 2026 16:04:45 +0100
Marco Elver <elver@google.com> wrote:

...
> I think the bigger issue was 'volatile': "Passing a volatile-qualified
> pointer to READ_ONCE() is an absolute
> trainwreck for code generation [...]" per dee081bf8f82.
> 
> While the above with the temporary is gone for the asm-generic
> version, the arm64 LTO still has the temporary and we need some
> qualifier-stripping helper.

I've done some real experiments, see https://www.godbolt.org/z/n9f91dGe3

If you don't strip the volatile you get a 'trainwreck'.
Visible on godbolt for the short sub-structure function f_v_s().
Fixable using __unqual_typeof__().

But the code for anything over 8 bytes is also a trainwreck.
eg: for an int[4] in a sub-structure:
	return __READ_ONCE(s->s_i).i[2];
f_s_i:
        sub     sp, sp, #16
        ldr     x8, [x0, #56]
        str     x8, [sp, #8]
        ldr     w8, [x0, #64]
        str     w8, [sp, #4]
        ldr     w9, [x0, #68]
        mov     w0, w8
        str     w9, [sp], #16
        ret
(The same code for a char[4] is fine...)

For integral types you can get a variable of the unqualified
type with:
	auto v = (typeof(x))0;
but that doesn't help here because the code needs to read short structures.

For long structures member by member access will give better code.
I'm not sure they should be allowed.
(and there may not be any.)

	David


  reply	other threads:[~2026-01-27 20:42 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
2026-01-27 15:04             ` Marco Elver
2026-01-27 18:54               ` David Laight [this message]
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=20260127185424.39d801ea@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