[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <193ca8cf-cf2c-9372-c0ab-16714ec37f57@rasmusvillemoes.dk>
Date: Mon, 7 Jun 2021 01:44:59 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Alexander Monakov <amonakov@...ras.ru>
Cc: Jakub Jelinek <jakub@...hat.com>,
Alan Stern <stern@...land.harvard.edu>,
Segher Boessenkool <segher@...nel.crashing.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will@...nel.org>,
Andrea Parri <parri.andrea@...il.com>,
Boqun Feng <boqun.feng@...il.com>,
Nick Piggin <npiggin@...il.com>,
David Howells <dhowells@...hat.com>,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Akira Yokosawa <akiyks@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-toolchains@...r.kernel.org,
linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC] LKMM: Add volatile_if()
On 07/06/2021 01.39, Rasmus Villemoes wrote:
> memory". Replacing with a call to an extern function marked pure does
> indeed cause gcc to cache the value of y*z, so in theory this should be
> possible, if one could convince gcc to "trust me, this really is a pure
> function".
Don't know why I didn't think to check before sending, but FWIW clang
doesn't need convincing, it already takes the __pure at face value and
caches y*z.
Rasmus
Powered by blists - more mailing lists