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 9843914A62B for ; Mon, 16 Feb 2026 17:43:28 +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=1771263809; cv=none; b=e/9AKhiXN0jn+ZYOQWJz/40P0LBW88KjSXRRWoiSYv5aNVnJHxxjLiqgA2M7bx0Pk3ovaOmS9MCYAfhRYv4e1YavsCb5jTjlv4F52ZFYoJhImAOdHzSePW7BoGM8xYNJWRDvLm2q4W17bBX7NekXU8hp5RSGx61IBZ220eRUMG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771263809; c=relaxed/simple; bh=NcORagMeFC/rvjQXS5vNE9v/gA3EGB9ocV8eIzFRpv0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jJDJyXEPTsYUEFVuUKVCSey6hpG9EJhUwYDboVhfiVTPJ9ZgDIIMK/Z7iWKUVbuciA68SdK0dCFB6wnIpHLKyYAt7NfFvbiZ0bqY22W0mghIZck3m5cQjbewWhStk5MuA7l8zneT973Sh40EVJMz3cIN3vVVPUSSSyUFvwfweqc= 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=KCytoOGk; 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="KCytoOGk" Received: by mail-wm1-f67.google.com with SMTP id 5b1f17b1804b1-48371bb515eso38632665e9.1 for ; Mon, 16 Feb 2026 09:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771263807; x=1771868607; 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=y/JQs8pM36d3KULNNrqatslwjR5gUtUOBzbMqn0DXdY=; b=KCytoOGkQbT6f2Ko1WnAY4WL+mAupPcen8B9/WRTjTVZbTd7g+hjUlXDPGaIrAEISD FEt92gMOeROpMFRRjqBCOfZsOKRPeu5bIdUVD901+qZ6iyIblGZuDMchAgs0YlndE0KU e02vYZUeBu12C43904qJp6QZ65GnO0Cr9G3HtEt3l9MjLvdTVGgvVG+yrjiUuXcCQzAN H4yLOQ3fg3hT0TgETLVwYfd9A4xU9o0CVRdYkhkEGBp0hg6Tbxo9GfBevuRzoBw8naYN +OVQqLbJaAG7SCIFuoyDT6MT1zOD6393+dFNmmefh1zavsIBY2OssavNexuVtSbggywz qHsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771263807; x=1771868607; 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=y/JQs8pM36d3KULNNrqatslwjR5gUtUOBzbMqn0DXdY=; b=J5thSiYDxWvRn17camUuA/+ZpM5jEESL3gz98YONqIc94cgAte9FQxguHIodUXoget zgXstozRSp34NsuZ4CFX6uTmK+MvAbVf8gbuEsDVcjOOTpZ0ZjZwm2uPHHmtU/Ie5HGJ hcQkf2nTsjx6XUVw5+fYXjMlLOVmXPPiKNQAOXNWV6KciEx81PKmphLsl/CJTvLJLrlt 3BHBVxSDswgG9173hu8qN0x7OCD/vU5MMtGrpl8znGn9712wIVrCUJlyLtuEdjWehmrw ckoEHwmFaeJVx7VB7nPZjg81glvHVTHOl0m/5z0r+F8IaOqYGj0H60oeg/c2P5bNQ5ST AehQ== X-Forwarded-Encrypted: i=1; AJvYcCXWyBreNkVjlg5xdVkgUyzU4BN0unselogne6DT39bgRNbdB6qEaHptW39glTMwfutf53bA/pCvclJH/7w=@vger.kernel.org X-Gm-Message-State: AOJu0YwJUOvh+1uY9t+EMBvPvvYYZ+QK3TqTFwDFxCkwU897aImb80GK 9sqwme4nyXsMW2A8PHPKQxjT2Pw5uHu0AnQ6x62vGOxgZzENIBmyvbNX X-Gm-Gg: AZuq6aJVuEeQ/+8gQE/q+Q6AHBarw54JIrJJmQtkUR4Xhp/iS9Zs77KZBa2IfD4xPzC FH3lO2BFnXTyjsEctR0rLBzZB7xLSKa4jFWbfoTlpnNeLoxXBN+pvD8sj2F+vbU2ZuhRX2hKCZO bqVU021HpvPqaHODvTVJbeLdLj+gKQloxVzAmNzgGbWAWYogwzy8EqzEB42uKdQj6H8xrmLsFG5 IxJ6xhj5jVNkV5nh41+a4x7WIlGWrpaoW6HTLZrmhlg8BaxgBConPs7cjqe2sEmd4xMmOZ0Pbl5 x1yGy6Hl50LpJQiFpsMMTo3xQcLtzjRFTYlsIzUXTPpz9zxMBwiEbmc4pvnCfSJN2RDkUZxi6yA oAX0cVaGSgwesBRGlMlYDaTt1Vv9mxVnRDBYBA75WPF8RXOrDx05yWSdSXzzPF3G3q/4PqT/28v v4g7p+REVzJ56/IJf3Jv6LlXMW0lvb6MgvnsuY/dFFk8sa2Op9loOeYodnJi/nSjrZ X-Received: by 2002:a05:600c:3d96:b0:480:f27c:6335 with SMTP id 5b1f17b1804b1-48373a66552mr194454965e9.25.1771263806667; Mon, 16 Feb 2026 09:43:26 -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 5b1f17b1804b1-4834d82a4afsm829023295e9.11.2026.02.16.09.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 09:43:26 -0800 (PST) Date: Mon, 16 Feb 2026 17:43:24 +0000 From: David Laight To: Linus Torvalds Cc: Marco Elver , 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 , Al Viro Subject: Re: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y Message-ID: <20260216174324.75d47e37@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> <20260215221656.68b2fc1d@pumpkin> <20260216110915.4f0d5490@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 Mon, 16 Feb 2026 07:32:53 -0800 Linus Torvalds wrote: > On Mon, 16 Feb 2026 at 03:09, David Laight wrote: > > > > volatile structure members are almost free > > No, gcc does absolutely horrible things with volatiles. It disables a > lot of very basic stuff. > > Try doing something as simple as a "var++" on a volatile, and cry. On x86 I just see a load, inc, store - not that surprising really. (clang did do 'inc memory'.) It's not as though 'inc memory' is atomic (without a lock prefix). Also var++ will be 3 u-ops the same as the read, inc, write so the underlying execution is much the same (ok you might save on the address generation and the compiler doesn't have to find a register name, but I don't remember anything modern being limited by instruction retirement). You might save a bit of I-cache. I've an idea that gcc converts var++ to 'var = var + 1' early on and then might manage to convert it back later. A good way of running out of registers, > > We need to have explicit 'READ_ONCE()' etc atomic accesses, just to > make it very very clear that the compiler will generate shit code. > > We do *not* hide them and make them implicit by marking data > structures volatile. I very much want those explicit > READ_ONCE/WRITE_ONCE cases. I guess you count as the boss :-) David > > Linus