Re: [PATCH] seqlock: Use WRITE_ONCE() when updating sequence
"Paul E. McKenney" <[email protected]>
| Newsgroups | org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <bfe737e8-5e5b-4fef-9346-06bbac57b2b3@paulmck-laptop> |
On Thu, Dec 19, 2024 at 05:45:15PM +0100, Florian Weimer wrote: > * Paul E. McKenney: > > > On Wed, Dec 18, 2024 at 08:56:07PM +0100, Florian Weimer wrote: > >> * Peter Zijlstra: > >> > >> > +linux-toolchains > >> > > >> > On Wed, Dec 18, 2024 at 08:59:47AM -0800, Paul E. McKenney wrote: > >> > > >> >> > Perhaps something like: (*(volatile unsigned int *)&s->sequence)++; ? > >> >> > I'd have to check what the compiler makes of that. > >> >> > > >> >> > /me mucks about with godbolt for a bit... > >> >> > > >> >> > GCC doesn't optimize that, but Clang does. > >> >> > > >> >> > I would still very much refrain from making this change until both > >> >> > compilers can generate sane code for it. > >> >> > >> >> Is GCC on track to do this, or do we need to encourage them? > >> > > >> > I have no clue; probably wise to offer encouragement. > >> > >> What do you consider sane code? > > > > Peter's "(*(volatile unsigned int *)&s->sequence)++;" qualifies as sane. > > I think the reference was originally to machine code. Very well, then compiling this to a to-memory increment instruction qualifies as sane. > >> Clang's choice to generate an incl instruction (on x86-64 at least) is a > >> bit surprising. Curiously, the C11 abstract machine has a value-less > >> increment-in-place operation, so it's probably not in violation of the > >> volatile rules. (C doesn't specify x++ in terms of ++x and x += 1.) > > > > Very good! Should I do something like file a bug somewhere to help > > this along? > > I don't know. It seems that Clang/LLVM is cheating. It's doing this > optimization even for > > i = i + 1; > > with a volatile i. That doesn't look like “strictly according to the > abstract machine” anymore. How so? It is in fact adding one to that volatile variable, which is in accord with the abstract machine. > A proper implementation would need explicit > representation of volatile increment/decrement in the IR. Given that > volatile increment/decrement is deprecated, that seems quite a bit of > effort. If I remember correctly, there was a discussion in SG21 about de-deprecating volatile increment/decrement. Thanx, Paul