From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 812D1CF319D for ; Wed, 2 Oct 2024 08:14:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 18D546B017B; Wed, 2 Oct 2024 04:14:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 118256B0274; Wed, 2 Oct 2024 04:14:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED30F6B0276; Wed, 2 Oct 2024 04:14:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C4C1C6B017B for ; Wed, 2 Oct 2024 04:14:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 453A21C71AE for ; Wed, 2 Oct 2024 08:14:12 +0000 (UTC) X-FDA: 82627949544.08.90C4419 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by imf16.hostedemail.com (Postfix) with ESMTP id 58B11180008 for ; Wed, 2 Oct 2024 08:14:08 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf16.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727856723; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F9AMyquBsYOwxmM+mEuOI0nyGFX4fyLc2AS7NRazJHU=; b=3YKTNWPUjTYCotGlrdvQkdaLwm2dIiQT2i5/Q2Pt76E6pvShSetboh3XNTmKG98aGUSZXx s8Ev5co2xbEyPpUISaHqSNE7LSu0r/KcQltPQJ15LFws6tgAqr9+JLIk0C8Un/YVe4mr0B SEQ5FryMHfT4poEqJofdGBW/nkUfN5Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727856723; a=rsa-sha256; cv=none; b=FShWzcQkdl6F9QjWjPLl0ikBNaErGM321neH9lu5cgVwY9G8c4IGL4Xa4g4j+Pmkz9owOn AzzduV/A1ZR1HPLZnaL23lWP3HoR2wMJSUz9Iyy5SUcScMLpGnNRGkqUVjHfss4Z7vAew9 RLBf/boVgn0ZD7ePfO8IrfYH9x4TDWQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf16.hostedemail.com: domain of david.laight@aculab.com designates 185.58.86.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-105-yxIePQGGMR-86E0GIzmtkQ-1; Wed, 02 Oct 2024 09:14:04 +0100 X-MC-Unique: yxIePQGGMR-86E0GIzmtkQ-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Wed, 2 Oct 2024 09:13:15 +0100 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Wed, 2 Oct 2024 09:13:15 +0100 From: David Laight To: 'Alan Stern' CC: Jonas Oberhauser , Mathieu Desnoyers , Linus Torvalds , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Sebastian Andrzej Siewior , "Paul E. McKenney" , Will Deacon , Peter Zijlstra , Boqun Feng , John Stultz , Neeraj Upadhyay , Frederic Weisbecker , "Joel Fernandes" , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Lai Jiangshan , Zqiang , Ingo Molnar , Waiman Long , "Mark Rutland" , Thomas Gleixner , Vlastimil Babka , "maged.michael@gmail.com" , Mateusz Guzik , Gary Guo , "rcu@vger.kernel.org" , "linux-mm@kvack.org" , "lkmm@lists.linux.dev" Subject: RE: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency Thread-Topic: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency Thread-Index: AQHbE2njI9qt6nx11kSrjhsE5O+AlrJyIkGggABQqYCAAKZugA== Date: Wed, 2 Oct 2024 08:13:15 +0000 Message-ID: <22638e2fe1274eb0834fa3e43b44184e@AcuMS.aculab.com> References: <20240928135128.991110-1-mathieu.desnoyers@efficios.com> <20240928135128.991110-2-mathieu.desnoyers@efficios.com> <02c63e79-ec8c-4d6a-9fcf-75f0e67ea242@rowland.harvard.edu> <9539c551-5c91-42db-8ac1-cff1d6d7c293@huaweicloud.com> <2cdda043-1ad9-40cf-a157-0c16a0ffb046@rowland.harvard.edu> <5d7d8a59-57f5-4125-95bb-fda9c193b9cf@huaweicloud.com> <82e97ad5-17ad-418d-8791-22297acc7af4@rowland.harvard.edu> <2b1caba3-48fa-43b9-bd44-cf60b9a141d7@rowland.harvard.edu> In-Reply-To: <2b1caba3-48fa-43b9-bd44-cf60b9a141d7@rowland.harvard.edu> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 58B11180008 X-Stat-Signature: zy3hsyuy3xnugnn9kmdijupfy9n8fu6f X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727856848-422686 X-HE-Meta: U2FsdGVkX19tw6Au/hCEQSeHLIsNC+H+yt8yuCCewAjN2gEutKnrg0SwoZFt6dU2erX7igkiRgkKwNW7+JY6nCvIlFkWo8+O5L/Kr7PLs1xHtaMAgXwH5fLjp3PWfS0eS6Jx4IUUC28Oc3458M0EH9VL4N+lc6N0jStEKuwu9s1TrdhM7hnNQbpnYMM5ulOAfwUdEQUgCxFBNPPwkBAG8Umgyb5c3RxkgKNzhkYMxXXEs0AMNx/44auYb6F03MdiRsDgZpnyLijrGC0ZStTlqQB1r/PPdMynlU3QrBmoxwFpCS9M3HQMX5P6KOhJEncTWoJa4PVpbm/3LJA0GHScmRELyYcdM4iXZmwMd0CUvUec9xInV0aVmrLDmhn5s5iSSIQczWR+pbKkV53iA7I8lreKJOJzt7t8DiazahmP1XFD4hUKcNka8BchD9CPvNj+frtaCjgQ1MZFCnJ4mmzlMTMU79AiCkfaWdoAWdSSS1v6kMGTGbTH0xHqTcZyDPlbeSuLbvZhuaJSRDYUGF/JQ/CeAglrwGvIPjmLpN3E2/wUjMQep2kjSwdJk1HlxJCCgFLuIi0sXtNKTkdNzhEkMqGK7APRgMJIYLsNol4hRfxJhccAQZSnE/kh22GhMSL+f5Jqm2RG7GmMSSrV3qXW+oYgYzLuqt++Fwd27OpJQt72l7gBaLQ+GK2wmAy5J8lduf9LnXngOsIqlUoXbHawbuRYhprngkaE9vi1eZ2k+x5cVx6DQ+zDtU48Uv4R+X/rivNlTX+JV46BLXsnuJ9EjRm+0+fhvwnQd9Te8Jq77xEX+xGxS2x7SU2hpEnVU/QRHyMElHezmFkSEGeAG6HV7i8QtNnNqQD2uZR+ZP+UtDBwssF8cZXfsMKDL1JIGUQnfWVvc7uW/ApW38NToNW97vK2GoYS6oTTULNwKE1Ra66PhUlupsSsdzqAmFtMIZdM5e7ubh+i6/DSr35evJ4 /g9v+zFa ySyT4rQSS5wIx/CwzbC6TgZDHlmXhXXdUXgmxjMducnMEFwR5m8cYw4A3qwF2D/hMFvxt70ianWB5hXy2puOSfnj5v+N8OFGSqIPwg7vttoFMDkauSIED5h4MxQUTsJ5GBQU11bxrG30PlNVn2823GwhOLFLDZglVIhIlsNsXlLKLcfG5ehvXWwbEpJB0S5NIgO94khgnRCGkgJkhNdvcamJ2gGhVlcD4Q/Sfl2CQtwC7HGtgzkhIBCTbGRGHWTVAFWxTJR51P7DbT2D4E5i8BPPoOy2+MYggpvGuu1C40TR2Adjjz7JDsBQw4+2b8RqeGX/1OeWT45CQzfDk8ytRetEDHK2ww2pNafwc5HkPtl+qaqU1CbLPCiCmzPJbymMLqHGLtQqdXNsHTK/o8df9OaGDj7hzMtzVdcnJlFUcBc9WLfZubM3slSHO9Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: 'Alan Stern' > Sent: 01 October 2024 23:57 >=20 > On Tue, Oct 01, 2024 at 05:11:05PM +0000, David Laight wrote: > > From: Alan Stern > > > Sent: 30 September 2024 19:53 > > > > > > On Mon, Sep 30, 2024 at 07:05:06PM +0200, Jonas Oberhauser wrote: > > > > > > > > > > > > Am 9/30/2024 um 6:43 PM schrieb Alan Stern: > > > > > On Mon, Sep 30, 2024 at 01:26:53PM +0200, Jonas Oberhauser wrote: > > > > > > > > > > > > > > > > > > Am 9/28/2024 um 4:49 PM schrieb Alan Stern: > > > > > > > > > > > > I should also point out that it is not enough to prevent the co= mpiler from > > > > > > using @a instead of @b. > > > > > > > > > > > > It must also be prevented from assigning @b=3D@a, which it is o= ften allowed to > > > > > > do after finding @a=3D=3D@b. > > > > > > > > > > Wouldn't that be a bug? > > > > > > > > That's why I said that it is often allowed to do it. In your case i= t > > > > wouldn't, but it is often possible when a and b are non-atomic & > > > > non-volatile (and haven't escaped, and I believe sometimes even the= n). > > > > > > > > It happens for example here with GCC 14.1.0 -O3: > > > > > > > > int fct_hide(void) > > > > { > > > > int *a, *b; > > > > > > > > do { > > > > a =3D READ_ONCE(p); > > > > asm volatile ("" : : : "memory"); > > > > b =3D READ_ONCE(p); > > > > } while (a !=3D b); > > > > OPTIMIZER_HIDE_VAR(b); > > > > return *b; > > > > } > > > > > > > > > > > > > > > > ldr r1, [r2] > > > > ldr r3, [r2] > > > > cmp r1, r3 > > > > bne .L6 > > > > mov r3, r1 // nay... > > > > > > A totally unnecessary instruction, which accomplishes nothing other t= han > > > to waste time, space, and energy. But nonetheless, allowed -- I agre= e. > > > > > > The people in charge of GCC's optimizer might like to hear about this= , > > > if they're not already aware of it... > > > > > > > ldr r0, [r3] // yay! > > > > bx lr > > > > > > One could argue that in this example the compiler _has_ used *a inste= ad > > > of *b. However, such an argument would have more force if we had > > > described what we are talking about more precisely. > > > > The 'mov r3, r1' has nothing to do with 'a'. >=20 > What do you mean by that? At this point in the program, a is the > variable whose value is stored in r1 and b is the variable whose value > is stored in r3. "mov r3, r1" copies the value from r1 into r3 and is > therefore equivalent to executing "b =3D a". (That is why I said one > could argue that the "return *b" statement uses the value of *a.) Thus > it very much does have something to do with "a". After the cmp and bne r1 and r3 have the same value. The compiler tracks that and will use either register later. That can never matter. Remember the compiler tracks values (in pseudo/internal registers) not variables. > > It is a more general problem that OPTIMISER_HIDE_VAR() pretty much > > always ends up allocating a different internal 'register' for the > > output and then allocating a separate physical rehgister. >=20 > What output are you referring to? Does OPTIMISER_HIDE_VAR() have an > output? If it does, the source program above ignores it, discarding any > returned value. Look up OPTIMISER_HIDE_VAR(x) it basically x =3D f(x) where f() is the identity operation: =09asm ("" : "+r"(x)) I'll bet that gcc allocates a separate internal/pseudo register for the result so wants to do y =3D f(x). Probably generating y =3D x; y =3D f(y); (The 'mov' might be after the asm, but I think that would get optimised away - the listing file might help.) So here the compiler has just decided to reuse the register that held the other of a/b for the extra temporary. =09David >=20 > > There doesn't seem to be a later optimisation path to remove > > 'pointless' register moves. >=20 > That would be a good thing to add, then. >=20 > Alan - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)