From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 62C46288C08 for ; Mon, 26 Jan 2026 19:54:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769457274; cv=none; b=OW5Ri86HZbwZTVa+jMxEGvOvrlN7aJlB5Mdc30KIa3bfNZluwpheT5DSqX2gD746Ct0zBSIgiK2eryyKcMRgQTZNzdwfPA7/sObuttKZDJVUXBi3fYgA/wjF5tgM84QPjPQ3OZWJgcDOqdvhjgIP3vZbBL7XX6luJZu1lZ3x0DQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769457274; c=relaxed/simple; bh=ViHUiOzDITl/2oYwnvg+mHOvHbAoJDAo1r8q6uy1Ihs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o+5i6ORyOfjhm1MNPuVVpPAwLJaAxurZkBg7pg14R6RHopyGbS6zamky+lMceZ+ZhD9f5ycXL/so+S/V+SDz88MpPJCvG+YXEVdRgDvLQOFSvEJUBwSI9z6NvhJKdY2jOLUpBnu1AK7MgfCM4Ree7s4oCRWc+WbzXoJ7HpkS408= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=YCIq5OF+; arc=none smtp.client-ip=209.85.128.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YCIq5OF+" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4801d98cf39so36152135e9.1 for ; Mon, 26 Jan 2026 11:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769457272; x=1770062072; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=EIvDHxjEBk/q7zSGk0OAMTPAzA3q+FQQ/WT+Ixk4ezQ=; b=YCIq5OF+ALEZeQmwkUudfQpEMhZ5/eGcn2+B86j1Tluln7w+6Z4UMFhaSQvagIEUAo WU3ok1N+Z6m/huJJvG/w2oYCv4awtgLDHJcHr0bFt4fu3dfuJpv7/UHkxmKDVYP/PlTH ZFKaowbnnDiXGIkBTpQum1yAkoy0H5M2WM9dCRp0oszVxBqWrd3a35MrWBM6BP7zRDyL DbznSwi5GojP/haOFwEiOhUNdGOt3pueVL+GiRg4mtuN/tjj2vEqWJOCUVLfQWTP13WH vFa+ulA2yfW3qDjTT4fSdcNhPBYVhTcpq7ONWuZ7Wht0HqIan/lShNlRRaISY2/4tAnd 6agg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769457272; x=1770062072; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=EIvDHxjEBk/q7zSGk0OAMTPAzA3q+FQQ/WT+Ixk4ezQ=; b=LSwZ6UlLwQWII4f/6WyVwkU5bt4QcpsHjw7OBs4AwCtzLm9v/EiCpp/mcpiwgIK67N 1AbTKc6YE0jbpBJz/wHi4LcSFwYqealuZNDDlrJCovsKeZwtjjNGzChjr2NP/X1JFmWo 7GociQxmr2nO1UKCeGtPia4bKi1gKja4LkKJ8OPwE8gUuhlQvsmufX5VIUgx0jwviJsV u9LwS3iFhkOA1Ll+StdeO5TahNvkmClUJBemC7WjvWQyN1Bkld5oAVcUIs9l+tMkH6Jg EGFvXI9M/SFIP6qeL2XqEEzgFgRbbZkys9hdbmT06MhNnrEW6YOWXiSkI3rzIb7ckD27 6yLw== X-Forwarded-Encrypted: i=1; AJvYcCWssVLrOCGPn96JhlYKwyQTHfJq3H7W4iOh4GhYb9MNyJB+hiponQjpFMma/IhlR3eG5WNAeJRoGw2khfc=@vger.kernel.org X-Gm-Message-State: AOJu0YyKZRmYmzdJbC+7Rlf0D+PRFIlUJsNfP/n3sDbCGQhLxjFJBwa6 0NdV9jUdKqKxgoin+gA3JCL93haVFiRAem2h8nTrZt9WTfjNuV2eCfpYexZ3xuP+Ig== X-Gm-Gg: AZuq6aIO360SmlG92uXVmyyuPVEChcoB+N1bDuOwBny+l2LYohtGirHy6jNAvvCA78T NOVX1C/bSOvK6sr0UCL889U7L9WM24Y1mS4k1C+uAdq+Mz0Hc3hgrG4TD5pIqo0cKlWlUwNqp3d BS3l+60lPu7r+seEGMRJI4rdYv+g60x4FWnJweG+EkBx8c9c1Z+dbADwNJOFNWCLcz+NI84zAi2 PrOlk84XHf6arhG2IXq9akxPdbDW2O12496DIRWikngitrTI9a1VheGvJhRnybvs4AOwH4HLJcT TFmeyY5TCoXoj7JgFjlcgGyRgfbUByiLh0PjyJmXEV6hPzjBwdbMrjLpMbiHSLzYfxuKFaqn0sK V7d4PKoCzq7N48vsI++C9LhtoUGtVHH/uoV1cHgpxWq4fdBsbzFfDUoRpFcooAzXGu+HdxgYJ3I FgY+Hz4iq6zZ6k73x/netpYERlQ6/h8d/qG8kZ7JbsIpB1o/Hp X-Received: by 2002:a05:600c:5248:b0:477:b734:8c41 with SMTP id 5b1f17b1804b1-4805cd4587emr88693725e9.1.1769457271541; Mon, 26 Jan 2026 11:54:31 -0800 (PST) Received: from elver.google.com ([2a00:79e0:2834:9:c598:7cce:ca6b:8ab7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee687sm22270685e9.5.2026.01.26.11.54.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 11:54:30 -0800 (PST) Date: Mon, 26 Jan 2026 20:54:24 +0100 From: Marco Elver To: Arnd Bergmann Cc: 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: References: <20260126002936.2676435-1-elver@google.com> <20260126002936.2676435-3-elver@google.com> 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-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.13 (2024-03-09) 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; })) +#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?