From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) (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 20FEC223DD6 for ; Sun, 15 Feb 2026 22:17:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771193821; cv=none; b=tRL4HzrWDdCl8ttA50SHYEkT6xR47s2jG7a8FiZr3UjT8At50IaTWTIjMZrcQHZ2gyY3nV6+Zl3PfOj1dbzHxb9PKxmoNgKNYKUA/cIzuCxHVn2X/9nktu5B6is3bWrIfsrgbY8qe0WPZz2OoN2aqCmRwX14T4N7G2m8Za5wxIQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771193821; c=relaxed/simple; bh=hJNZsiHjZFwnJ9fS95IR9Tp7m0vT5l6IZphGtg/FmiE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fk9iwUm0TqfcYcPgz+5OttTvMfS3Pf5IjrRhFOoL1W0ha5msX5riGzQ6Xq2BsNx6bRzeAe3MM378B21hNmATRhpstXGvQWlEtbKt+tI51IL21uSRugVQZqiEz+BtOKDNAecsxHiASuSDAS9RLla+PlhrnHG2QJ/zD4knOFjXFoc= 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=Lwut8W7a; arc=none smtp.client-ip=209.85.128.67 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="Lwut8W7a" Received: by mail-wm1-f67.google.com with SMTP id 5b1f17b1804b1-48374014a77so20884315e9.3 for ; Sun, 15 Feb 2026 14:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771193818; x=1771798618; 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=IDmUias2s0pvnhz4ZeDjGfgxnsQChrumnkaZhgFLeFw=; b=Lwut8W7aZ8O+TNJcIm5zMiVq4G5kf2HP0CCNYv5pVKcHYoX3juwRy6r/TCSejsex7U fD3of0cVDj1RYUP4ZDutz1w6NqT0h4Q2eNGicdoeaI+wa5Q+6PVkdvufWTFpqpltoe1s pxaPEUlCreYB0JOaktD9cYmBAhSai/tzQMlWwmmbTj6eGMzgVmu0JdU338Ekk7wqLbNu jObF+a4lIc9pzHqnQYTmboeNG+q776vPXSu388rSHdYf7bXpupg2OOlrhB6arPrf8MJ0 JYJr6812p7tf250w/rAq+IgvpINJ49b1zQOsARhenLIvOIcSTZR+J2460QeJgqWW4FLN 3W3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771193818; x=1771798618; 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=IDmUias2s0pvnhz4ZeDjGfgxnsQChrumnkaZhgFLeFw=; b=blvlVxR0gZgqPXLGLahRc9TfQMfACkW8ZVnoUS1uQVcG+MifExJ5Hv81QLHCQZTuyD yhw/Hqwr5xFuNEGrp+SknRH+Euv3uJJg1+B20WtTdV8v449YoGi2vH1bH5lCGMKD+TiS ztxe6m8Vqt3js8ykAYG9pWyvy+nlOq4kttLPLea45vyFjSiwNmsmaJAl4yu0kiGSyT02 ZWnpA3EO1BrYnaGrxWHbqojKaVWSC9DLrmMm2n72+BsytuRhmNuFYF3eGIRyY4pL7NqU 20iyAVnPak1VIRwYDMp2Fpc1D1j34tq6lFdrgocj6oigUMZGeJzrG8v9jxn0HcDVJ075 rP4w== X-Forwarded-Encrypted: i=1; AJvYcCVSpCofzh0urIhmYzl7UVHVse6ctCZ29j9IyD/HAoDFCQ9egcgYZJoa+nZJ0MZjsS6Kukxvwl6BtHXNFFQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yxiw0RrKa3YH3hOiH3tf/wOjtsh5C+AE22sLMF0ez/e0OfRVpbA wVNUiHr1akEnYoC6q2rQo8Bd1h3uLj4snki8uCNDtkGl+ni2P5cWA631 X-Gm-Gg: AZuq6aKOaGo+xMUsDdnQm7vnPIbodi0rVlrth83V3mibtIXv71q1dVa2TB4F/H8hn80 icCYHit66GXKwWLnecaiOi7gJ2DgX5NBIPiqg8aMKFHKEak+7sCapS8Ly6280wVoBTvOYLP9MgO DChKrc40GS7n3CNVfJoC6nIrc2WgFpFBrv+U0BLlC9tT/dyfah5lchq8IS7c6IU4Mze//BSmw9Q +SHPKeW+QbxZw1U2/fQNVR5vYuMU5C8+5+8DYzo7IRQIw1LWgztksDw5pXncWSBIM/obYvuY9wU WdG7x5fjTj+6CSbfZUVDdgO9GrcWsAH+qZHh/X78AtMmKBVn/1B+kUlQ72PEmvVG8B1Vil++Kwi ESDyxmLv4LOfBi/uwdD12Fvq68JVH0KMFaQhYds+W38Kr8WSoPgM73XC9/WnC9jIt5IeXgxwcv8 AieE42Y9HYzBY3ZOgRROYqZQuMCAXA/A9rRXbrpmKQhAZSME2KBS9xP2MUrBBeHnsF X-Received: by 2002:a05:600c:6211:b0:477:93f7:bbc5 with SMTP id 5b1f17b1804b1-48373a09741mr161305915e9.10.1771193818234; Sun, 15 Feb 2026 14:16:58 -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-43796a5d156sm24535875f8f.5.2026.02.15.14.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 14:16:57 -0800 (PST) Date: Sun, 15 Feb 2026 22:16:56 +0000 From: David Laight To: Marco Elver Cc: Will Deacon , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Boqun Feng , Waiman Long , Bart Van Assche , llvm@lists.linux.dev, Catalin Marinas , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel test robot , Boqun Feng , Linus Torvalds , Al Viro Subject: Re: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y Message-ID: <20260215221656.68b2fc1d@pumpkin> In-Reply-To: References: <20260130132951.2714396-1-elver@google.com> <20260130132951.2714396-4-elver@google.com> <20260202192923.0707e463@pumpkin> <20260204131400.GI2995752@noisy.programming.kicks-ass.net> <20260206182650.6c21b0ff@pumpkin> 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 Sun, 15 Feb 2026 22:55:44 +0100 Marco Elver wrote: > On Fri, 6 Feb 2026 at 19:26, David Laight wrote: > > On Fri, 6 Feb 2026 16:09:35 +0100 > > Marco Elver wrote: > > > > > On Wed, 4 Feb 2026 at 15:15, Will Deacon wrote: > > > > > > > > On Wed, Feb 04, 2026 at 02:14:00PM +0100, Peter Zijlstra wrote: > > > > > On Wed, Feb 04, 2026 at 11:46:02AM +0100, Marco Elver wrote: > > > > > > On Tue, 3 Feb 2026 at 12:47, Will Deacon wrote: > > > > > > [...] > > > > > > > > > What does GCC do with this? :/ > > > > > > > > > > > > > > > > GCC currently doesn't see it, LTO is clang only. > > > > > > > > > > > > > > LTO is just one way that a compiler could end up breaking dependency > > > > > > > chains, so I really want to maintain the option to enable this path for > > > > > > > GCC in case we run into problems caused by other optimisations in future. > > > > > > > > > > > > It will work for GCC, but only from GCC 11. Before that __auto_type > > > > > > does not drop qualifiers: > > > > > > https://godbolt.org/z/sc5bcnzKd (switch to GCC 11 to see it compile) > > > > > > > > > > > > So to summarize, all supported Clang versions deal with __auto_type > > > > > > correctly for the fallback; GCC from version 11 does (kernel currently > > > > > > supports GCC 8 and above). From GCC 14 and Clang 19 we have > > > > > > __typeof_unqual__. > > > > > > > > > > > > I really don't see another way forward; there's no other good way to > > > > > > solve this issue. I would advise against pessimizing new compilers and > > > > > > features because maybe one day we might still want to enable this > > > > > > version of READ_ONCE() for GCC 8-10. > > > > > > > > > > > > Should we one day choose to enable this READ_ONCE() version for GCC, > > > > > > we will (a) either have bumped the minimum GCC version to 11+, or (b) > > > > > > we can only do so from GCC 11. At this point GCC 11 was released 5 > > > > > > years ago! > > > > > > > > > > There is, from this thread: > > > > > > > > > > https://lkml.kernel.org/r/20260111182010.GH3634291@ZenIV > > > > > > > > > > another trick to strip qualifiers: > > > > > > > > > > #define unqual_non_array(T) __typeof__(((T(*)(void))0)()) > > > > > > > > > > which will work from GCC-8.4 onwards. Arguably, it should be possible to > > > > > raise the minimum from 8 to 8.4 (IMO). > > > > > > That looks like an interesting option. > > > > > > > That sounds reasonable to me but I'm not usually the one to push back > > > > on raising the minimum compiler version! > > > > > > > > > But yes; in general I think it is fine to have 'old' compilers generate > > > > > suboptimal code. > > > > > > > > I'm absolutely fine with the codegen being terrible for ancient > > > > toolchains as long as it's correct. > > > > > > From that discussion a month ago and this one, it seems we need > > > something to fix __unqual_scalar_typeof(). > > > > > > What's the way forward? > > > > > > 1. Bump minimum GCC version to 8.4. Replace __unqual_scalar_typeof() > > > for old compilers with the better unqual_non_array hack? > > > > > > 2. Leave __unqual_scalar_typeof() as-is. The patch "compiler: Use > > > __typeof_unqual__() for __unqual_scalar_typeof()" will fix the codegen > > > issues for new compilers. Doesn't fix not dropping 'const' for old > > > compilers for non-scalar types, and requires localized workarounds > > > (like this patch here). > > > > > > Either way we need a fix for this arm64 LTO version to fix the > > > context-analysis "see through" the inline asm (how this patch series > > > started). > > > > > > Option #1 needs a lot more due-diligence and testing that it all works > > > for all compilers and configs (opening Pandora's Box :-)). For option > > > #2 we just need these patches here to at least fix the acute issue > > > with this arm64 LTO version. > > > > Option 3. > > > > Look are where/why they are used and change the code to do it differently. > > Don't forget the similar __unsigned_scalar_typeof() in bitfield.h. > > (I posted a patch that nuked that one not long ago - used sizeof instead.) > > > > The one in minmax_array (in minmax.h) is particularly pointless. > > The value 'suffers' integer promotion as soon as it is used, nothing > > wrong with 'auto _x = x + 0' there. > > That will work elsewhere. > > Agreed that getting rid of __unqual_scalar_typeof() in favor of 'auto' > where possible is the way to go. > > Unfortunately I spent the last week occasionally glancing at this > arm64 READ_ONCE problem, and could not come up with something that > avoids using typeof_unqual() or __unqual_scalar_typeof(). I'm inclined > to go with the unqual_non_array hack, but not make this available as a > macro for general use - we have too many of these horrid macros, don't > want to add more to this hack pile. Agreed, having to do such things inside what are already horrid 'functions' is one thing, but when they get used in 'normal' code it is silly. Have you checked whether sizes other than 1, 2, 4 and 8 are ever used? There aren't any in an x86-64 allmodconfig build and it used to be an error. Even if there are handful, having to use a different define wouldn't really be an issue. Removing that support would make READ_ONCE() easier to write/understand and (hopefully) compile faster - there is a measurable cost for the 'size check' in the x86-64 build, the arm LTO expansion must be significant. David