Re: [PATCH] seqlock: Use WRITE_ONCE() when updating sequence
Florian Weimer <[email protected]>
| Newsgroups | org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
* 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. >> 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. 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. Thanks, Florian