On Tue, Oct 31, 2023 at 04:49:56PM +0000, Michael Matz wrote:
> Hey,
>
> On Tue, 31 Oct 2023, Peter Zijlstra wrote:
>
> > > equivalent to that, then it can't be used in this situation. If you
> > > _have_ to use a RmW for other reasons like interrupt safety, then a
> > > volatile variable is not the way to force this, as C simply doesn't have
> > > that concept and hence can't talk about it. (Of course it can't, as not
> > > all architectures could implement such, if it were required).
> >
> > Yeah, RISC archs typically lack the RmW ops. I can understand C not
> > mandating their use. However, on architectures that do have them, using
> > them makes a ton of sense.
> >
> > For us living in the real world, this C abstract machine is mostly a
> > pain in the arse :-)
>
> Believe me, without it you would live in a world where only languages like
> ECMA script or Rust existed, without any reliable spec at all ("it's
> obvious, the language should behave like this-and-that compiler from 2010
> implements it! Or was it 2012?"). Even if it sometimes would make life
> easier without (also for compilers!), at least you _have_ an arse to feel
> pain in! :-) Ahem.
You mean like Rust volatiles considering conflicting accesses to be
data races? That certainly leads me to wonder how a Rust-language device
driver is supposed to interoperate with Rust-language device firmware.
They currently propose atomics and things like the barrier() asm to make
that work, and their definition of atomic might just allow it.
> > > So, hmm, I don't quite know what to say, you're between a rock and a hard
> > > place, I guess. You have to use volatile for its effects but then are
> > > unhappy about its effects :)
> >
> > Notably, Linux uses a *ton* of volatile and there has historically been
> > a lot of grumbling about the GCC stance of 'stupid' codegen the moment
> > it sees volatile.
> >
> > It really would help us (the Linux community) if GCC were to be less
> > offended by the whole volatile thing and would try to generate better
> > code.
> >
> > Paul has been on the C/C++ committee meetings and keeps telling me them
> > folks hate volatile with a passion up to the point of proposing to
> > remove it from the language or somesuch. But the reality is that Linux
> > very heavily relies on it and _Atomic simply cannot replace it.
>
> Oh yeah, I agree. People trying to get rid of volatile are misguided.
> Of course one can try to capture all the individual aspects of it, and
> make individual language constructs for them (_Atomic is one). It makes
> arguing about and precisely specifying the aspects much easier. But it
> also makes the feature-interoperability matrix explode and the language
> more complicated in areas that were already arcane to start with.
Agreed, and I have personally witnessed some primal-scream therapy
undertaken in response to attempts to better define volatile.
> But it's precisely _because_ of the large-scale feature set of volatile
> and the compilers wish to cater for the real world, that it's mostly left
> alone, as is, as written by the author. Sure, one can wish for better
> codegen related to volatile. But it's a slippery slope: "here I have
> volatile, because I don't want optimizations to happen." - "but here I
> want a little optimization to happen" - "but not these" - ... It's ... not
> so easy :)
And to your point, there really have been optimization bugs that have
broken volatile. So I do very much appreciate your careful attention
to this matter.
> In this specific case I think we have now sufficiently argued that
> "load-modify-store --> rmw" on x86 even for volatile accesses is a correct
> transformation (and one that has sufficiently local effects that our heads
> don't explode while thinking about all consequences). You'd have to do
> that for each and every transformation where volatile stuff is involved,
> just so to not throw out the baby with the water.
Understood!
> > > If you can confirm the above about validity of the optimization, then at
> > > least there'd by a point for adding a peephole in GCC for this, even if
> > > current codegen isn't a bug, but I still wouldn't hold my breath.
> > > volatile is so ... ewww, it's best left alone.
> >
> > Confirmed, and please, your SMP computer only works becuase of volatile,
> > it *is* important.
>
> Agreed.
Good to hear!!!
Thanx, Paul
