From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4700123D2A1 for ; Mon, 26 Jan 2026 22:55:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769468156; cv=none; b=OY0d55KIM8B8U6iDpL/7CgRjv4U2W+7cVTZ6x0189ehFKxHSerspABJIC/zAi4gx6LLsaA8m5rlhIKnojqZPA6WKdJVHDz3zq9FfCEtQiHRLwIXzmuTDVzd+bCFVCinitjcDw4c4CZmFas01BK/5VATq/tTo+ohhZ2by+D+r7Ko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769468156; c=relaxed/simple; bh=YO6I+oOwPvpy+5QZq0erhp7w5mJ6l7+UXtplL2rDHIE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NCYpT/kX+zafBdt/9dSjA0HFsEqq6pfkg8qBa5J/0G/pBNc47FCpc0suUoePhY/Ts3EpojCqW9WsRQNb+xjssTggvSscOu/GRFyRNJ1Ynf5rQudalS/wOxsd8S3fL2xgCRL0MndF9TLjv5drJAp3/usJbaSEoraiIT0O6FuUO8A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BkjYYIcz; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BkjYYIcz" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-432d256c2e6so4801211f8f.3 for ; Mon, 26 Jan 2026 14:55:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769468154; x=1770072954; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=4IjqB7GheMfendzLAj5XKvDdIe71cAYrEVZFcl0Ddts=; b=BkjYYIczO3lRb682zZm58T6rZGF7blTFFH75zttbg3VAsk9CZk+5jIshY+YSeFZSeG ukMVSmosfZofbUa1O6l8XxemlBzhnoeTma2U9wlm8Ac6NpYgLB/iqecPoMcfzIz2yt/Z DBUTiG0e3u17pN0gpZz3aOnpALM3HdkWUgKgprUrHniz5h8GiIHg1xNkBzJ+9SkGzQ1/ 6ORU8iBWwmC6jMWhX41avnCFm3bSJpYlUbZNx9sPXTtBJAP+SR8TcpocTZ8cCV90SDEh SaO1VshVZsw/f3/X16ytFU7xJFhMhhK8k9GTHBmXaEs+xEMazKEZvMzAe8SEf4CU2tPk +bjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769468154; x=1770072954; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4IjqB7GheMfendzLAj5XKvDdIe71cAYrEVZFcl0Ddts=; b=ghNsvr1tpSmn/BBjGcSx3qYL7s85CC8mU/mXKWHdGgP0zT1VQYE/0KQ4f4nFYZzMsv M2mDrxfymLSpLIWu/LXlL1NqfroiHQdH7vNO4g5oX0Drgb6xQ58boAhcMElIOqrS/brL F1SaB17Fg8+MwgC9p2JAe10u9RwLSJqiVEZjQ/s6P+3ifWfSXWKAWSf3OWUg8bfqA0KM DG7gvwMAJ77zWsSgRpCzrIp4OspCoisEssl87hiHiuDf0VAq5zOMQNfqG/M4Qld9on3p 2v39M3j6Ts6pTKqi0aAyQI4k8wush8s12MYtIeC+P5BUtUfVlbSfjSGe0su6aCrPEowQ Yd0A== X-Forwarded-Encrypted: i=1; AJvYcCUY/nssgNap9RGQEYcasZkICRkVkTeuhihFlNP2s10FVg8fjTswWX2VreAFGv64R9xXkbJ1FJ7+6jLTpGc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywrd804Zrgx5mWZMiUVxSmgngz1STYNV/AYcDuvMqJM70VJnA0d nHY2F5a8VBYnS0s7Q0M4FeyAhnktDpEEi2y0codWl2XnZtwl49Iw6N1R X-Gm-Gg: AZuq6aI+era0QaqYYqX00d4TiRxqCeCt6ONeMVY4136hfdZZ62HTInAwp27wuYPgBUr FqXo6xa4MYixoaTgmOi4Ro+y+QiLrMwSVFs+7t9aT6TlnUilAnMK9Eve6yYa69k8DexWZx+44gV sUleYUEiXiNhkvtgurXtpyZJ/y0ZAe6S1jpUcqttDgmu5W3fK4BamWLwo6YghQDFZIFa++EUmnr o0FlUCqS161NlrwziCQZscnuuXZ2GN9Rmet3ibD/L7+yaTY2cjvszhLufN333lFGtUU6of+/mFB Rs4YgS4LOtlACq0GaDfdgPt5AFkTdeTuHUiMo49vcKzFEHz2c0z4G7QYlFex3IjXeO7cf6oK0eQ Nx1lPZLowa691vICpvQOn2AaevbvTpF55vdHxbYO4coqtN3itmxVTbTBJ+7NPO/RxBD3ucg02c6 9lfGNlwep8i1bGknjr3UDoU+VS68OcUp4/Z/l7hSP5ftk0+vO/y01p X-Received: by 2002:a05:6000:2483:b0:430:fd0f:28fe with SMTP id ffacd0b85a97d-435ca1ac717mr8971008f8f.31.1769468153426; Mon, 26 Jan 2026 14:55:53 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c02c91sm33226100f8f.9.2026.01.26.14.55.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 14:55:53 -0800 (PST) Date: Mon, 26 Jan 2026 22:55:46 +0000 From: David Laight To: Marco Elver Cc: Arnd Bergmann , Peter Zijlstra , Will Deacon , Ingo Molnar , Thomas Gleixner , Boqun Feng , Waiman Long , Bart Van Assche , llvm@lists.linux.dev, Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] arm64: Optimize __READ_ONCE() with CONFIG_LTO=y Message-ID: <20260126225546.30d96049@pumpkin> In-Reply-To: References: <20260126002936.2676435-1-elver@google.com> <20260126002936.2676435-3-elver@google.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 26 Jan 2026 20:54:24 +0100 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: > > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > > index fc0fb42b0b64..9963948f4b44 100644 > > > --- a/arch/arm64/include/asm/rwonce.h > > > +++ b/arch/arm64/include/asm/rwonce.h > > > @@ -32,8 +32,7 @@ > > > #define __READ_ONCE(x) \ > > > ({ \ > > > typeof(&(x)) __x = &(x); \ > > > - int atomic = 1; \ > > > - union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \ > > > + union { TYPEOF_UNQUAL(*__x) __val; char __c[1]; } __u; \ > > > switch (sizeof(x)) { \ > > > case 1: \ > > > asm volatile(__LOAD_RCPC(b, %w0, %1) \ > > > > 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. > > > 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: > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > index 85b1dd7b0274..d6c808cc01be 100644 > --- a/arch/arm64/include/asm/rwonce.h > +++ b/arch/arm64/include/asm/rwonce.h > @@ -19,6 +19,18 @@ > "ldapr" #sfx "\t" #regs, \ > ARM64_HAS_LDAPR) > > +#ifdef USE_TYPEOF_UNQUAL > +#define __read_once_typeof(x) TYPEOF_UNQUAL(x) > +#else > +/* > + * Fallback for older compilers to infer an unqualified type, using the fact > + * that __auto_type is supposed to drop qualifiers. Unlike typeof_unqual(), the > + * type must be complete (defines an unevaluated local variable). This must > + * already be guaranteed because sizeof(x) is used in the __READ_ONCE macro. > + */ > +#define __read_once_typeof(x) typeof(({ __auto_type ____t = (x); ____t; })) Did you try old versions of gcc? gcc before 11.0 don't drop qualifiers. Even const int y=0; __auto_type x = +y; generates a 'const' x (same for - and ~). You need to do '0+y' to lose the const. None of them help here because you don't want the integer promotion. Can you use: union { u8 u8v, u16, u16v, u32 u32v, u64 u64v } u; Then get the asm to write to the correct sized u.unn, then finish with: *(typeof(*x))&u; or does that spill to stack for 'ptr to volatile'? It doesn't solve the problem for other sized items, but I'm not sure how many there really are. If a handful changing them to READ_BIG_STRUCT_ONCE() shouldn't be a real problem. David > +#endif > + > /* > * When building with LTO, there is an increased risk of the compiler > * converting an address dependency headed by a READ_ONCE() invocation > @@ -32,8 +44,8 @@ > #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; \ > switch (sizeof(x)) { \ > case 1: \ > > > Thoughts? >